Re: [whatwg] Drag-and-drop feedback

[Roland Steiner]

Since I am currently in the process of fixing bugs in this area for Chrome,
there are 2 things I'm wondering about:

.) whether "Text" and "URL" should be part of the return value of "types"
(probably not, according to Ian's comment). However, since "text/uri-list"
may in fact not contain a valid URL, the presence/absence of "URL" in types
could be useful. I.e., it could indicate whether getData("URL") will return
something useful.

.) Judging from the example in
https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , Firefox
seems to use only LF for line feeds within text/uri-list, while RFC 2483
calls for CR-LF for all "text/*" formats, including "text/uri-list", as does
the HTML5 spec in the section on the drag-and-drop processing model.
Since the UA has to parse "text/uri-list" for the return value of "URL", I
wonder whether both should be accepted (break on LF, filter out any CR). The
other problem here is that WebKit/Safari and Chromium convert files to file
URLs to return for "text/uri-list"/"URL". Is there a consensus how this
difference should be best handled (or is this just a bug in FF)?


Cheers,

Roland


On Thu, Feb 4, 2010 at 11:29 AM, Ian Hickson  wrote:

> Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but
> case-insensitively (at least for Text, I didn't test URL). Chrome is
> case-insensitive for everything.
>
> Tough call. I guess we'll go with just converting everything to lowercase,
> so that it's case-insensitive.
>
> BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's
> incorrect according to the spec.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

[whatwg] Why are video's width & height DOMString?

[Yaar Schnitman]

Hi,

According to [1], the video's width & height attributes are DOMString, but
according to [2] width & height "must have values that are valid
non-negative integers".
Shouldn't they be long then?

Digging deeper, I found that video, iframe, embed and object all have
DOMString width & height attributes, but img specifies width & height to be
long [3]. For consistency, shouldn't all of them be the same?

Thanks,
Yaar

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video

[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element

Re: [whatwg] Drag-and-drop feedback

[Ian Hickson]

On Thu, 4 Feb 2010, Daniel Cheng wrote:
> On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson  wrote:
> > On Thu, 4 Feb 2010, Daniel Cheng wrote:
> > > >
> > > > Webkit and Firefox are case-sensitive. IE only does "TEXT" and 
> > > > "URL", but case-insensitively (at least for Text, I didn't test 
> > > > URL). Chrome is case-insensitive for everything.
> > > >
> > > > Tough call. I guess we'll go with just converting everything to 
> > > > lowercase, so that it's case-insensitive.
> > > >
> > > > BTW I noticed Chrome includes "Text" and "URL" in the .types list. 
> > > > That's incorrect according to the spec.
> > >
> > > If event.dataTransfer converts everything to lowercase, that means 
> > > there are native formats that will always be impossible to access.
> >
> > The spec requires that the UA lowercase all the native types as well 
> > (and that they be converted to MIME types).
> >
> > Could you elaborate on which types would be a problem, and on what 
> > platforms?
> 
> Forcing UA to lowercase all formats has a high implementation cost.

It's not _that_ high. It's just a few strings, and it's easily cachable.


> Most DataTransfer implementations now can directly interact with the 
> native system data object, whatever form that takes. With this change, 
> the UA has to enumerate (with possible string conversions involved, 
> depending on the platform) and lower case all formats currently in the 
> drag and drop/clipboard operation with every call to 
> getData()/setData()/clearData(). Furthermore, what happens if there are 
> collisions after lowercasing?

The spec requires that the UA convert the formats to MIME types, so the UA 
is responsible for preventing collisions.


> Also, suppose some Windows app XYZ uses the data format "My Awesome 
> Clipboard Format". If a page wants to set drag and drop (or clipboard 
> data; presumably, the interfaces to transfer data are going to remain 
> somewhat similar), it will be unable to set data in the correct format 
> unless the UA happens to internally map a MIME type to that data format.

Yes.


> Some common MIME types should definitely be mapped to native data 
> formats, but the interface shouldn't prevent someone from interfacing 
> with any arbitrary app they want.

I'm open to changing this again, but if it is to change again I want to 
make sure we never change it after that, so we need to be very sure about 
what the spec should say here.

Exactly what conversions should happen? When?

If you could work with other browser vendors to come up with the exact 
rules for dataTransfer that everyone agrees makes sense on every platform, 
that would be ideal.

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

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson  wrote:

> On Thu, 4 Feb 2010, Daniel Cheng wrote:
> > >
> > > Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL",
> > > but case-insensitively (at least for Text, I didn't test URL). Chrome
> > > is case-insensitive for everything.
> > >
> > > Tough call. I guess we'll go with just converting everything to
> > > lowercase, so that it's case-insensitive.
> > >
> > > BTW I noticed Chrome includes "Text" and "URL" in the .types list.
> > > That's incorrect according to the spec.
> >
> > If event.dataTransfer converts everything to lowercase, that means there
> > are native formats that will always be impossible to access.
>
> The spec requires that the UA lowercase all the native types as well (and
> that they be converted to MIME types).
>
> Could you elaborate on which types would be a problem, and on what
> platforms?
>

Forcing UA to lowercase all formats has a high implementation cost. Most
DataTransfer implementations now can directly interact with the native
system data object, whatever form that takes. With this change, the UA has
to enumerate (with possible string conversions involved, depending on the
platform) and lower case all formats currently in the drag and
drop/clipboard operation with every call to getData()/setData()/clearData().
Furthermore, what happens if there are collisions after lowercasing?

Also, suppose some Windows app XYZ uses the data format "My Awesome
Clipboard Format". If a page wants to set drag and drop (or clipboard data;
presumably, the interfaces to transfer data are going to remain somewhat
similar), it will be unable to set data in the correct format unless the UA
happens to internally map a MIME type to that data format. Some common MIME
types should definitely be mapped to native data formats, but the interface
shouldn't prevent someone from interfacing with any arbitrary app they want.


>
>
> > Since "text" and "url" are already special, maybe case should only be
> > ignored for those two. All other formats, even if they are actually MIME
> > type strings, should be handled in a case-sensitive manner.
>
> In your previous e-mail, you were arguing they should be
> case-insensitive... I think your earlier arguments are more persuasive.
> The MIME type specs do say they're case-insensitive.
>

True, but I think the problems with making all strings lowercase outweigh
the benefits.


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

Re: [whatwg] Drag-and-drop feedback

[Jian Li]

On Wed, Feb 3, 2010 at 6:29 PM, Ian Hickson  wrote:

> On Sat, 23 Jan 2010, Eduard Pascual wrote:
> >
> > Would it be possible to provide a list of "drag items" (to call them
> > somehow) instead of, or in addition to, the current info provided by the
> > DataTransfer object?
>
> That's a pretty good idea. I think we should probably do this when we add
> more types to the DataTransfer object.
>
>
> On Sat, 23 Jan 2010, Maciej Stachowiak wrote:
> > >
> > > The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model
> > > that it is based on) doesn't really work for this case anyway,
> > > regardless of the copy/paste issue, since there doesn't seem to be any
> > > sane way to distinguish between an in-page drag and a drag to an
> > > external application such as a clipboard. If you can drag to a
> > > clipboard, I don't see why we would _disallow_ the copy/paste
> > > interaction.
> >
> > That sounds like a design flaw with the drag and drop model.
>
> One of many.
>
>
> > Sounds like something to fix not something to compound with another
> > design flaw.
>
> Fair enough. I've removed the copy/paste mode of drag-and-drop.
>
>
> I'll deal with the copy/cut/paste events separately.
>
>
> On Mon, 25 Jan 2010, Jian Li wrote:
> > > >
> > > > "DownloadURL". The data associated with the "DownloadURL" format
> > > > should be parsed similar to the "URL" format. When the drag ends in
> > > > another application, the remote file described in the associated
> > > > data URL should be downloaded and provided to the target
> > > > application.
> > >
> > > How would this be exposed to other apps? Is it possible in Windows to
> > > drop something and then have the application that received the drop
> > > wait for a download (which could take hours) to complete? How does
> > > that work?
> >
> > On Windows, [...] we use the file stream to transfer the data between
> > the source application and the target application and thus the target
> > application will not be blocked if it uses a background thread (this is
> > what Windows Shell does). On MacOSX, a file stream is also used for such
> > purpose.
> >
> > However, we need to provide more metadata about the download when we
> > call DataTransfer.setData("DownloadURL", ...). This is because on
> > Windows we need to know about the file name and size when the drag is
> > initiated. We can wait till we get the headers to extract the file name
> > and size but this is blocking. Even more, if the http chunk mode is
> > used, we cannot get the size from the headers.
>
> So how would you provide the file size?
>

After more investigation, I found out that we do not need file size info in
order to unblock the UI thread of Shell on Windows. This is because we can
use delayed rendering plus IAsyncOperation when dragging and dropping to
Windows Shell. However, many other target applications do not support these
advanced interfaces and thus could be blocked if the download takes long
time. Since dropping to Shell desktop or folder is the main scenario we want
to deal with, I think we're OK with this solution.

>
>
> > On MacOSX, we need to provide the mime type and file name. Could we
> > consider adding mime type, file name and size information into the data
> > value parameter of setData method? For example,
> >
> >dataTransfer.setData("DownloadURL", "text/plain:1000:
> http://example.com/download.txt";);
>
> I think we should just have a "promise" mechanism rather than one
> hard-coded for URLs. But I think it's probably best for us to wait until
> we have the current spec implemented reliably and sanely before adding
> something like that. We don't even have a good test suite for the
> drag-and-drop API yet.
>
> Yes, we probably need a better mechanism to describe the drag data. After
we get implementations up in all applicable platforms, we can have a good
understanding of what are needed and what are not and then we can define a
better API.

>
> On Mon, 25 Jan 2010, Michael Davidson wrote:
> > > >
> > > > The issue that I'm having is that if the DataTransfer object says
> > > > that it has Files, I have no way to determine what type those files
> > > > are. (In this case, I only want to accept image files.) I understand
> > > > that the DataTransfer shouldn't have the content of the files for
> > > > security reasons, but it would be helpful if it did contain the file
> > > > names and/or MIME types.
> > >
> > > I could provide a second attribute with the types of the files, would
> > > that work? I suppose if we did this, we should remove the "Files" fake
> > > type. That might not be a bad idea in general, it's kind of a hack.
> > > I'm not sure how I feel about having multiple different ways of
> > > representing the data in a DataTransfer object... It would give a
> > > clean precedent for adding other features, though, like promises,
> > > which some people have requested.
> >
> > Multiple different ways to get the same info doesn't seem great, but it
> > doe

Re: [whatwg] Drag-and-drop feedback

[Ian Hickson]

On Thu, 4 Feb 2010, Daniel Cheng wrote:
> >
> > Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", 
> > but case-insensitively (at least for Text, I didn't test URL). Chrome 
> > is case-insensitive for everything.
> >
> > Tough call. I guess we'll go with just converting everything to 
> > lowercase, so that it's case-insensitive.
> >
> > BTW I noticed Chrome includes "Text" and "URL" in the .types list. 
> > That's incorrect according to the spec.
> 
> If event.dataTransfer converts everything to lowercase, that means there 
> are native formats that will always be impossible to access.

The spec requires that the UA lowercase all the native types as well (and 
that they be converted to MIME types).

Could you elaborate on which types would be a problem, and on what 
platforms?


> Since "text" and "url" are already special, maybe case should only be 
> ignored for those two. All other formats, even if they are actually MIME 
> type strings, should be handled in a case-sensitive manner.

In your previous e-mail, you were arguing they should be 
case-insensitive... I think your earlier arguments are more persuasive. 
The MIME type specs do say they're case-insensitive.

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

Re: [whatwg] api for fullscreen()

[Kit Grose]

On 05/02/2010, at 8:08 AM, David Singer wrote:
> On Feb 3, 2010, at 15:03 , Kit Grose wrote:
>> I feel that the user shouldn't have the ability to enter into some sort of 
>> "pseudo-fullscreen". If the content needs to be displayed full-screen,
> 
> I don't believe that there is any such 'need' and that the user should own 
> that decision.  I, for example, basically refuse to use applications that 
> have the hubris to assume that they should own the screen and cover all the 
> parts they don't need with gray.  I didn't buy a large display to see grey 
> painted everywhere;  I bought it so I *could* see multiple things at once.

I agree that such behaviour is not always desirable and that prudent 
application developers should design their applications such that full-screen 
is not necessary. If a user chooses not to enter full-screen, giving the 
developer that information permits them to provide a suitable alternative 
interface; transparently providing an in-window experience will simply limit 
the ability to use fullscreen mode for things like comprehension tests, games 
that capture the mouse/keyboard as input methods and must hide the cursor, etc.

So long as the user has the ability to escape fullscreen simply, the fullscreen 
API would behave more or less the same way as the fullscreen API in desktop 
application environments. That developers have the ability to build horrible 
interfaces is an unfortunate but necessary side effect of giving them useful 
APIs.

>> If the user does not wish to view the content in full-screen and the 
>> developer feels that content can only be reasonably viewed full-screen,
> 
> The developer has no idea how big my screen is, how many I have, or a host of 
> other questions.

The developer has access to your screen size via the window.screen object. I 
agree that it's presumptuous of a developer to insist on full-screen in many 
(most?) situations, but for applications that require full-screen conceptually 
(as opposed to applications that need to run large) I don't believe screen size 
should be a factor.


By the sounds of things I'm pretty certain we're in agreement that fullscreen 
capabilities should be used sparingly as a matter of UX; I too have multiple 
(large) monitors, and as a Mac user tend to layer windows instead of running 
anything "maximised". I also develop kiosk and medical applications where 
fullscreen is not only desirable but necessary behaviour. Crippling the API 
such that the developer cannot determine whether or not the user permitted 
their application to run fullscreen is unnecessary—it's up to developers to use 
the API in a usable manner, and up to UAs to provide an easy "escape hatch" if 
the developer fails to do so, just like in desktop environments.

—Kit

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Aryeh Gregor]

On Thu, Feb 4, 2010 at 12:44 PM, Michal Zalewski  wrote:
> The same argument could be made for not escaping <, but I don't think
> it's valid in practice - particularly for (hypothetically) constrained
> input fields.

The use-cases for srcdoc are only where you expect HTML input.  HTML
input is very likely to contain " or '.  By contrast, ordinary XSS
usually occurs when < is unlikely to occur in legitimate input, so you
won't spot it right away -- as you say, constrained input fields.  Why
would anyone, even someone who's extremely confused and/or ignorant,
even *attempt* to use srcdoc to contain anything other than HTML?

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

>
> Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but
> case-insensitively (at least for Text, I didn't test URL). Chrome is
> case-insensitive for everything.
>
> Tough call. I guess we'll go with just converting everything to lowercase,
> so that it's case-insensitive.
>
> BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's
> incorrect according to the spec.


If event.dataTransfer converts everything to lowercase, that means there are
native formats that will always be impossible to access. Since "text" and
"url" are already special, maybe case should only be ignored for those two.
All other formats, even if they are actually MIME type strings, should be
handled in a case-sensitive manner.

Daniel

Re: [whatwg] Window id - a proposal to leverage session usage in web application

[Sebastian Hennebrueder]

Tim Hutt schrieb:

On 4 February 2010 20:49, Sebastian Hennebrueder  wrote:

What is the idea about?


I think "Web Storage" does what you want and is already implemented
(apparently even in IE). The description from the spec:

"This specification introduces two related mechanisms, similar to HTTP
session cookies, for storing structured data on the client side.

The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
different windows at the same time.

Cookies don't really handle this case well. For example, a user could
be buying plane tickets in two different windows, using the same site.
If the site used cookies to keep track of which ticket the user was
buying, then as the user clicked from page to page in both windows,
the ticket currently being purchased would "leak" from one window to
the other, potentially causing the user to buy two tickets for the
same flight without really noticing.

To address this, this specification introduces the sessionStorage IDL
attribute. Sites can add data to the session storage, and it will be
accessible to any page from the same site opened in that window.

For example, a page could have a checkbox that the user ticks to
indicate that he wants insurance:


 
 I want insurance on this trip.

A later page could then check, from script, whether the user had
checked the checkbox or not:

if (sessionStorage.insurance) { ... }
If the user had multiple windows opened on the site, each one would
have its own individual copy of the session storage object."


Hi Tim,

thank you for the feedback. I hope that I see your point correctly. You 
are right, that for JavaScript based applications this can easily be 
solved with a sessionStorage. All technologies around GoogleWebToolkit, 
Dojo, Echo etc which hold the state in the client and make use of a 
stateless server side application can use the session storage to 
distinguish browser windows.


But there are a lot of web technologies which hold the state on the 
server using the browser session. Technologies like Ruby on Rails, 
JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them. 
Those technologies can not make a simple use of the session storage. 
They are only aware of the browser session which is a common space of 
all browser windows. The windows id let them split the session in a per 
browser window scope.


Originally, when playing with the window id concept, I simulated a 
window id by storing it in a session storage and adding it with the help 
of JavaScript as parameter to all links and as hidden field to all 
forms. It works to some extend but it pollutes the URL and is likely to 
cause problems with bookmarking and there is a use case where it fails. 
If you open a link in a new windows. In that case the first request is 
sending the wrong windows id.



--
Best Regards / Viele Grüße

Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de

Re: [whatwg] api for fullscreen()

[David Singer]

On Feb 3, 2010, at 15:03 , Kit Grose wrote:
> I feel that the user shouldn't have the ability to enter into some sort of 
> "pseudo-fullscreen". If the content needs to be displayed full-screen,

I don't believe that there is any such 'need' and that the user should own that 
decision.  I, for example, basically refuse to use applications that have the 
hubris to assume that they should own the screen and cover all the parts they 
don't need with gray.  I didn't buy a large display to see grey painted 
everywhere;  I bought it so I *could* see multiple things at once.

> If the user does not wish to view the content in full-screen and the 
> developer feels that content can only be reasonably viewed full-screen,

The developer has no idea how big my screen is, how many I have, or a host of 
other questions.

> I feel the user has opted not to view that content at all. I don't mind at 
> all that the user has no choice but to skip that content; it's similar 
> behaviour to a user quitting a desktop application that insists on running 
> full-screen.


Indeed.

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] Window id - a proposal to leverage session usage in web application

[Tim Hutt]

On 4 February 2010 20:49, Sebastian Hennebrueder  wrote:
> What is the idea about?

I think "Web Storage" does what you want and is already implemented
(apparently even in IE). The description from the spec:

"This specification introduces two related mechanisms, similar to HTTP
session cookies, for storing structured data on the client side.

The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
different windows at the same time.

Cookies don't really handle this case well. For example, a user could
be buying plane tickets in two different windows, using the same site.
If the site used cookies to keep track of which ticket the user was
buying, then as the user clicked from page to page in both windows,
the ticket currently being purchased would "leak" from one window to
the other, potentially causing the user to buy two tickets for the
same flight without really noticing.

To address this, this specification introduces the sessionStorage IDL
attribute. Sites can add data to the session storage, and it will be
accessible to any page from the same site opened in that window.

For example, a page could have a checkbox that the user ticks to
indicate that he wants insurance:


 
 I want insurance on this trip.

A later page could then check, from script, whether the user had
checked the checkbox or not:

if (sessionStorage.insurance) { ... }
If the user had multiple windows opened on the site, each one would
have its own individual copy of the session storage object."

[whatwg] Window id - a proposal to leverage session usage in web application

[Sebastian Hennebrueder]

Hi all,

About half a year ago I came up with an idea to add a unique window id 
as request header to each browser request. I published this initially on 
my website

http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html

About a week ago, I have stumbled upon the WebApps Working Group which 
sent me over to the whatwg user group.


What is the idea about?
The browser should generate an id unique per browser window and sent it 
as request header with every browser request.

Request Header
--
X-Window-Id: 279078917624897

This allows to identify which windows sent a request and helps to 
leverage the use of the HTTP session in multi page web application. I 
will describe this in more detail below.


Why is it useful?
Imagine you want to use accordion style menus (sample: JQuery UI - 
http://jqueryui.com/demos/accordion/) or menu groups like the one of JSF 
Richfaces 
(http://livedemo.exadel.com/richfaces-demo/richfaces/panelMenu.jsf?c=panelMenu&tab=usage). 



If you want to show the same menus or widgets opened after a page 
reload, then you need to memorize somehow what is opened or closed. We 
need to keep track of the application's state.


Using the REQUEST
We could store the information in the request. As a consequence, every 
form and link of our screen needs to include a list of opened 
menus/widgets. This could be achieved by manipulating all links and 
forms using JavaScript.


The advantage is that it works with multiple windows and does not 
require a user session. The disadvantage is that it pollutes the request 
and enlarges the data sent by every request. In an application with a 
lot of stateful information it could be impossible to follow this approach.


Using the SESSION
The other solution is to store the state in the users session. Every 
time a menu/widget is opened, we send an Ajax request to keep track of 
opened menus. The downside of session usage is that it is impossible to 
use multiple windows in the browser because they would overwrite other 
window's state (opened menus). This is because a user session is 
normally stored as browser cookie and cookies are merged into a single 
space for all browser windows (new exception: secure browser windows)


Using the Window id
Having a window id, we can save the list of opened menus/widgets per 
window in the user session. We split up the user session in slices. In 
pseudocode it looks like this:

id = request['x-window-id']
context = session[id]
menus = context['menus']

It is quite interesting that HTML 5 solves the problem for the client 
side of JavaScript applications. The sessionStorage allows fine grained 
controll if data is seen by all windows or just by the current. The 
problem only persists for client – server applications.


Another use case are dialogs or conversations which span multiple pages. 
We could think of a complex dialog to edit an item or the checkout 
process of a shop application. With a windows id, we know that the 
complex dialog was started in a window and that the user is now visiting 
another area. This allows to clean up the session area for this window.


I created a plugin for Firefox which adds the window-id to a request. 
You can use my ruby based sample application to test the be behaviour.


You can find the original article, the plugin etc in my blog.

http://www.laliluna.de/blog/categories/ideas/

I am looking forward to your feedback.

--
Best Regards / Viele Grüße

Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de

Re: [whatwg] Canvas size and double buffering.

[Robert O'Callahan]

On Fri, Feb 5, 2010 at 3:25 AM, Brian Campbell wrote:

> On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote:
>
> > On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell 
> wrote:
> > I think the most reasonable approach would be to say that the
> getBoundingClientRect().width or height is rounded to the nearest pixel.
> Boxes are displayed rounded to the nearest pixel, with no fractional pixels
> being drawn, right?
> >
> > No.
>
> In what cases are fractional pixels drawn? I see fractional widths being
> returned here, but it seems to be drawing rounded to the nearest pixel:
>
> http://ephemera.continuation.org/percentage-width.html
>

Box edges are (usually) snapped to the nearest *device pixel* boundary. That
is not the same as rounding the CSS pixel width or height to the nearest
integer.

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

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Michal Zalewski]

> Not escaping " is so easily and quickly discovered that I really don't
> think that's a problem.

The same argument could be made for not escaping <, but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.

>> That would be great. I think Adam proposed we have a separate
>> sandbox="..." toggle for this. Whether it's on or off by default
>> probably doesn't matter much.
> Adam's feedback (not quoted here, but in the same thread as the e-mail to
> which this is a reply) suggests that this is actually a bad idea, so I've
> not changed this.

There are obvious, existing usage cases where sites struggle to
prevent automated resource loading across domains - e.g., almost every
HTML-supporting mail client; so it strikes me that if we go along with
this reasoning because a perfect solution may not exist, we're also
effectively saying that what they are doing should not be attempted at
all (then what's the alternative? one should probably be a part of
HTML5).

> If there's no HTML, there's no need for a sandbox, so the simplest
> solution is just to escape the > Keep in mind that pretty much every web application already needs to
>> safely generate unique, unpredictable tokens - for session identifiers
>> that guard authenticated sessions. If they can't get it right, they are
>> hosed anyway - but problems here are not horribly common, in my
>> experience at least, and web app frameworks do a decent job of helping
>> developers by providing token-generating facilities.
>
> Pretty much the same can be said of escaping text.
>
> Also, based on Adam's comments, it seems that things aren't really as rosy
> as all that for token generators.

I think the difference is huge; in a typical web framework, you need
to explicitly escape every single piece of potentially dangerous
attacker-controlled input to stay safe - and because people tend to do
some validation at input stage, it's very difficult to audit for it.
Escaping also needs to be very different depending on the context
(URLs need to be encoded differently than HTML parameters, and
differently than standalone text).

So even though your framework may provide several escape() functions,
it's very easy to get it wrong, and people constantly do. OTOH, if
your framework provides a get_token() function, there's really not
that much to using it properly.

I'm coming from a background of doing lots of security reviews for
existing applications, so while I appreciate that the difference may
be subtle, the real-world error patterns speak to me pretty strongly;
and I do think that insufficient escaping is drastically more common
than used, but insufficiently unpredictable XSRF tokens.

/mz

Re: [whatwg] Qs about element

[Tab Atkins Jr.]

On Thu, Feb 4, 2010 at 6:51 AM, Philippe Wittenbergh  wrote:
> On Feb 4, 2010, at 9:21 PM, Ian Hickson wrote:
>>> 2) What should UAs do when printing? It seems to me that, when printing,
>>> a  element should be open, regardless of the state of the
>>> boolean open attribute. (because it's a markup attribute, there is
>>> presumably now way for a print stylesheet to override this). Can that be
>>> added to the spec?
>>
>> Generally speaking, browser vendors have found that people expect their
>> "print" features to just print what's on the screen. However, I'm
>> certainly open to changing the spec on this if the browser vendors feel
>> the spec should change -- any implementors have an opinion on this?
>
> As a page author and site developer (and as a user), I would certainly want 
> the possibility to display the content of the details element when printing, 
> insofar as it is relevant to the document in a printed state.
> (that is, a print stylesheet should be able to override the onscreen display 
> state of )

The  implementation will likely be nothing more than this CSS
(roughly):

details:not([open]) > :not(summary:first-of-type) { display: none; }

So it should be easily overrideable in a print stylesheet.

~TJ

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Tab Atkins Jr.]

On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson  wrote:
> On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
>>
>> Adam Barth rightfully points out that this only stops certain classes
>> of data exfiltration attacks, and so probably isn't worthwhile as a
>> solution to that matter.  However, I think this would also be very
>> useful for general comments, to prevent, for example, shock trolls
>> from putting goatse images in your comment threads.  It would also
>> prevent  and  embeds from working.
>>
>> However, it would still allow the site owner to allow particular files
>> to be embedded with , , or , if they just host them
>> on their own origin and set allow-same-origin in the sandbox flags.
>> This is already a relatively normal practice, but it's accomplished
>> through attempts at filtering.
>>
>> Note that this would also prevent resource embeds using data urls, as
>> they have a unique origin.
>
> It seems like if you want to control what markup is shown, the way to do
> that is to to parse the input and remove the elements you want to block.
> Just blocking off-domain images is a pretty poor way of blocking images if
> that's what you want to do. Consider that the commentor could just use
>  and  to embed an "image" if that's what he wants to
> do.

Heh, if someone goes to the trouble of constructing a pixelmap out of
a table, they deserve to have it up until I find it and delete it.
Note as well that this sort of thing wouldn't be stopped by the
suggested "parse and sanitize" method either, unless you just want to
strip *all* tables.  And pretty much all other HTML (using div/span
with display:table-* would accomplish the same thing, or just putting
explicit heights/widths on them to make the 'cells' line up.)

> On many large sites, users can upload images to one part of the site
> -- those wouldn't be blocked either.

That's the point - one wouldn't want those blocked (or if one did, one
could indeed filter all images out).  They can perhaps be more subject
to moderation (submit the image, and have to wait for it to be
approved before you can use it), or just be a built-in set of images
that you're allowed to use, like the large sets of smilies that most
forums have.

>> Sorry, the title is unclear - I mainly intend this as preventing
>>  and the like.  Any sort of action that could be both
>> annoying and would take place without the user's consent.  This is
>> inherently ill-defined, which may be a problem, but it could be
>> tightened up to say precisely which features should be shut down.  It
>> might need to be revised as new features get added, though.
>
> Yeah, maybe we should do this. Are there any other than autoplay,
> autofocus, , and 

Re: [whatwg] Canvas size and double buffering.

[Brian Campbell]

On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote:

> On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell  
> wrote:
> I think the most reasonable approach would be to say that the 
> getBoundingClientRect().width or height is rounded to the nearest pixel. 
> Boxes are displayed rounded to the nearest pixel, with no fractional pixels 
> being drawn, right?
> 
> No.

In what cases are fractional pixels drawn? I see fractional widths being 
returned here, but it seems to be drawing rounded to the nearest pixel:

http://ephemera.continuation.org/percentage-width.html

> Why would they report a width or height that is different than how they are 
> displayed? All browsers that I've tested (the ones listed above, so not IE) 
> report integral values for getBoundingClientRect().width and height (or for 
> left and right in the case of Opera, which doesn't support width and height).
>  
> Firefox often returns non-integral values for getBoundingClientRect().width 
> or height.

Sorry, I meant to write "but Firefox", but somehow missed that. Safari, Chrome, 
and Opera all return values rounded to the nearest pixel.

-- Brian

Re: [whatwg] behavior

[Michael A. Puls II]

On Thu, 04 Feb 2010 03:47:22 -0500, Ian Hickson  wrote:


On Tue, 26 Jan 2010, Michael A. Puls II wrote:


Please see the note in the  element section. It has more
detailed info. The embed and applet elements have the old, less-detailed
note.


Yeah. It turns out that trying to make the paragraph that's in the
 section fit the  and  sections makes it read
poorly, which is why I phrased it differently. The gist is the same,
which is what matters. It's only an informative note, after all.


O.K., that's cool.

--
Michael

Re: [whatwg] Qs about element

[Philippe Wittenbergh]

On Feb 4, 2010, at 9:21 PM, Ian Hickson wrote:

>> 2) What should UAs do when printing? It seems to me that, when printing, 
>> a  element should be open, regardless of the state of the 
>> boolean open attribute. (because it's a markup attribute, there is 
>> presumably now way for a print stylesheet to override this). Can that be 
>> added to the spec?
> 
> Generally speaking, browser vendors have found that people expect their 
> "print" features to just print what's on the screen. However, I'm 
> certainly open to changing the spec on this if the browser vendors feel 
> the spec should change -- any implementors have an opinion on this?

As a page author and site developer (and as a user), I would certainly want the 
possibility to display the content of the details element when printing, 
insofar as it is relevant to the document in a printed state.
(that is, a print stylesheet should be able to override the onscreen display 
state of )

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/

Re: [whatwg] an odd example of the meter element

[Ian Hickson]

On Thu, 29 Oct 2009, Futomi Hatano wrote:
> 
> I found an odd example in the meter element section of the spec. 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element
> 
> max: 100; current: 75
>
> According to "steps for finding one or two numbers of a ratio in a 
> string", does it means that the actual value is 100 and the max value is 
> 75?

I've removed that algorithm entirely, so that's no longer an issue. 

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

Re: [whatwg] Qs about element

[Ian Hickson]

On Thu, 4 Feb 2010, Bruce Lawson wrote:
> 
> 1) I read that  doesn't require any authorial scritping to 
> work, and that a details element should expand/ contract for user agents 
> that have JS disabled. Is that correct?

Yes, assuming the browser supports it.


> 2) What should UAs do when printing? It seems to me that, when printing, 
> a  element should be open, regardless of the state of the 
> boolean open attribute. (because it's a markup attribute, there is 
> presumably now way for a print stylesheet to override this). Can that be 
> added to the spec?

Generally speaking, browser vendors have found that people expect their 
"print" features to just print what's on the screen. However, I'm 
certainly open to changing the spec on this if the browser vendors feel 
the spec should change -- any implementors have an opinion on this?

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

Re: [whatwg] Supporting eviction in WebStorage

[Ian Hickson]

On Thu, 24 Dec 2009, Kyle Scholz wrote:
>
> A common application of WebStorage will be clientside caching. Since 
> there are limits on store size, developers will be implementing eviction 
> schemes, but this is currently difficult because the interface doesn't 
> expose store size or get/set times for entries. Some additions to the 
> Storage interface would support most use cases:
>
> totalSize() - Indicates the absolute size of the store.

Different UAs will use different storage mechanisms, leading to different 
sizes for the same content. It's not clear exactly how to define this, 
especially now that values can be types other than strings.


> availableSize() - Indicates available space in the store.

This is even harder to define. We considered it in depth about a year ago, 
but in the end couldn't find a way to define this interoperably.


> keysByAccessTime() - Returns a list of keys in ascending order by access time.
> accessItem() - Sets the access time of an entry to now.
> 
> setItem() will always set the access time of an item. getItem() will
> not set the access time of an item. This makes it possible for the
> developer to determine whether they wish to enable a
> least-recently-stored or least-recently-accessed eviction policy. A
> developer should follow calls to getItem() with a call to accessItem()
> if they wish eviction candidates to be ordered by access time.

I agree that this could be useful in a future version, but in the 
meantime, authors can fake it by storing the time manually in a parallel 
key, so I haven't added it yet. It'll be interesting to see if people do 
this, or if it isn't actually that important.

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

Re: [whatwg] history.back()

[Ian Hickson]

On Fri, 29 Jan 2010, Olli Pettay wrote:
> On 1/29/10 3:32 AM, Ian Hickson wrote:
> > 
> > I've tried to spec this. There is a high risk of compatibility issues, 
> > so I would very much welcome feedback from implementors who try to 
> > implement this.
> > 
> > The main goal of the change here is to make it possible to implement 
> > this (if not completely sanely, but it's the Web, there's only so much 
> > I can do) in a situation with each browsing context having its own 
> > process, as seen to some extent in IE and Chrome, and as is being 
> > examined by other browser vendors also.
>
> So why sync history isn't possible in IE or Chrome?

Anything's _possible_, it's just that it's a lot more complicated. As 
Jonas said earlier in the thread, making history traversal asynchronous is 
likely to make things easier for Mozilla too. Sorry for overstating the 
case above, I have a tendency to exaggerate!


> How should UA handle this case? User presses back (which hopefully does 
> pretty much the same as history.back()) but web page has some loop like 
> script which sets location.hash all the time.

I would recommend that implementations prioritise tasks queued by user 
interaction, so that the script does not preempt the user's action. 
However, since that is a user interface issue, the spec does not specify 
it in any detail. (The spec doesn't require that you expose a back button 
at all.)


> > If we can't do this asynchronously, it's going to really suck for 
> > multiprocess UAs,
>
> Depends for example on whether UA wants to put different domains in same 
> tab to different processes. And even if it does do, synchronous 
> back()/forward() should be possible. Maybe just not as easy. So I'm not 
> sure that "suck for multiprocess UAs" is a really good argument here.

Certainly it isn't well-expressed, but it does seem important to make sure 
that the technology we are specifying can be sanely implemented in a 
multi-process architecture, since two UAs are already shipping with that 
technology, and at least one other (Mozilla) is working on a similar 
effort. I don't think anyone would deny that there are advantages to such 
an approach.


> Uh, changing hashchange again to async. We must stop changing that all 
> the time. Though in this case I like the change. I never really 
> understood the sync hashchange, or the reasoning why it was changed to 
> be sync.

Yeah, my apologies for the back-and-forth on this particular issue. I try 
to minimise churn in general, but in this case I failed.


> So history.back(); history.back(); would queue 2 tasks?

Yes.


> And first one document is loaded (maybe from bfcache), and it could
> synchronously do something like dispatch pageshow or whatever which
> could do things like alert() and then second document was loaded at somepoint.
> Kind of strange way to handle history.back().

For cross-document loads, back() has always been asynchronous, so I don't 
think that particular case is a change.

I agree that it is not completely intuitive.

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

Re: [whatwg] Qs about element

[Anne van Kesteren]

On Thu, 04 Feb 2010 12:26:10 +0100, Bruce Lawson  wrote:

Couple of questions about the  element, raised by Shelley Powers
in  comments to an article I wrote on html5 doctor
http://html5doctor.com/summary-figcaption-element/

1) I read that  doesn't require any authorial scritping to work,
and that a details element should expand/ contract for user agents that
have JS disabled. Is that correct?


Yeah, once UAs have native support.


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

[whatwg] Qs about element

[Bruce Lawson]

Hi

Couple of questions about the  element, raised by Shelley Powers
in  comments to an article I wrote on html5 doctor
http://html5doctor.com/summary-figcaption-element/

1) I read that  doesn't require any authorial scritping to work,
and that a details element should expand/ contract for user agents that
have JS disabled. Is that correct?

2) What should UAs do when printing? It seems to me that, when printing, a
 element should be open, regardless of the state of the boolean
open attribute. (because it's a markup attribute, there is presumably now
way for a print stylesheet to override this). Can that be added to the
spec?

--


Bruce Lawson
www.brucelawson.co.uk
-

sent from my ZX80

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Ian Hickson]

On Mon, 25 Jan 2010, Michal Zalewski wrote:
> > 
> > This has been proposed before. The concern is that many authors would 
> > be likely to make mistakes in their selection of "random" tokens that 
> > would lead to significant flaws in the deployment of the feature.
> >
> > srcdoc="" is less prone to errors. Only " and & characters need to be 
> > escaped. If the " character is not escaped, then a single " character 
> > in the input will cause the comment to break.
> 
> My counterargument, as stated later in the thread, is quite simple: the 
> former *forces* you to implement a security mechanism, else the 
> functionality will break. You can still use a bad token, but you are 
> required to make the effort.
> 
> In that regard, the comparison to XSRF is probably not valid; a vast 
> majority of XSRF bugs occurs not because people pick poor tokens (in 
> fact, that's really a majority), but because they don't use them at all. 
> From that perspectiv, srcdoc="..." is very similar to XSRF - people will 
> mess it up simply by not thinking about the correct escaping.

Not escaping " is so easily and quickly discovered that I really don't 
think that's a problem. The difference between that and XSRF is that in 
the XSRF case, things usually work pretty well (better than well, in fact, 
even HTML is supported!). It's only if an attacker makes use of the hole 
that the side-effect is highlighted.

The idea here is to align what is needed for correctness and what is 
needed for security, rather than having them be separate. In that way it's 
quite similar to the token idea, except I think it's far more likely to be 
done securely -- actually picking a truly unpredictable token is a 
non-trivial exercise.


> That said, I am not really arguing against srcdoc="..."; I think it's an 
> OK feature. My point is simply that I would love to see less 
> fragmentation when it comes to XSS defenses and the granularity of 
> security controls. The initial proposal of  sandboxes solved a 
> very narrow use case, and other, unrelated designs started to spring up 
> elsewhere. This wouldn't be bad by itself, but while the security 
> controls on  were pretty great (with some tweaks, such as 
> text/html-sandboxed), they would not be reflected in other APIs, which I 
> thought is unfortunate.
> 
> If we extend sandboxed iframes with srcdoc, seamless frames, 
> text/html-sandboxed, and  rendering performance improvements, it 
> actually becomes close to a comprehensive solution, and I am happy with 
> this (other than a vague feeling that we just repurposed  to be 
> some sort of a  ;-).

Well, it's different from  because it has its own browsing context 
-- which is basically exactly what  is.


> > I've introduced text/html-sandboxed for this purpose.
> 
> 1) Some other security mechanisms (CORS, anti-clickjacking controls, XSS 
> filter controls) rely on separate HTTP headers instead. Is there a 
> compelling reason not to follow that lead - or better yet, to unify all 
> security headers to conserve space?

We need something that breaks legacy UAs.


> 2) People may conceivably want to sandbox other document types (e.g., 
> SVG, RSS, or other XML-based formats rendered natively, and offering 
> scripting capabilities). Do we want to create "-sandboxed" MIME types 
> for each? The header approach would fix this, too.

If people really use XML, we can add an equivalent MIME type for XML. 
However, we should only do so if that's really required.


> >> 2.1) The ability to disable loading of external resources (images, 
> >> scripts, etc) in the sandboxed document. The common usage scenario is 
> >> when you do not want the displayed document to "phone home" for 
> >> privacy reasons, for example in a web mail system.
> >
> > Good point. Should we make sandbox="" disable off-origin network 
> > requests?
> 
> That would be great. I think Adam proposed we have a separate 
> sandbox="..." toggle for this. Whether it's on or off by default 
> probably doesn't matter much.

Adam's feedback (not quoted here, but in the same thread as the e-mail to 
which this is a reply) suggests that this is actually a bad idea, so I've 
not changed this.


> >> 2.2) The ability to disable HTML parsing. [...]
> 
> One use case is a web forum or a web mail interface where you want to 
> display a message, but specifically don't want HTML formatting. Or, 
> performance permitting, the same could be used for any text-only entry 
> fields displayed on a page.

If there's no HTML, there's no need for a sandbox, so the simplest 
solution is just to escape the , and also have to 
escape "s).


> > Do people get CSRF right more often than simply escaping characters? 
> > It seems implausible that authors get complex cryptographic properties 
> > right more often than a simple set of substitutions, but I suppose 
> > stranger things are true on the Web.
> 
> Keep in mind that pretty much every web application already needs to 
> safely generate unique, u

Re: [whatwg] Canvas size and double buffering.

[Nikita Popov]

I tried to solve the aliasing problem in Firefox and found out, that it 
really isn't possible to get it right, if you set the width and height 
in CSS:
If you leave the css-width/height as it is when resizing the canvas, it 
will get blurred in Firefox. If you change it to 'auto' it won't resize 
correctly next time.
So the only possibility is to get sharp lines and correct sizing is to 
first set the css-width/height procentually in JavaScript, then set the 
canvas.width/height using getBoundingClientRect and than setting 
css-width/height to 'auto'. (Everything on every resize). Furthermore 
you have to add one Pixel to the width if it isn't dividable by 2, 
because Chrome would add a strange white line otherwise.


So here is how it looks: http://nikic.lima-city.de/canvastest2.html
Works in Firefox and Google Chrome.

Sorry for double post.

Re: [whatwg] Canvas size and double buffering.

[Nikita Popov]

Am 04.02.2010 01:00, schrieb Tim Hutt:

On 3 February 2010 23:16, Boris Zbarsky  wrote:
   

On 2/3/10 6:12 PM, Tim Hutt wrote:
 

Ah yes that works nicely
   

Hmm maybe I spoke too soon. The interaction of the CSS size and the
canvas.width/height is confounding! It seems if you set a CSS width
of, say 80% then that is that and you are stuck with it. Unfortunately
it doesn't round to the nearest pixel!

I have created a test case here:

http://concentriclivers.com/canvas.html (the source is nicely
formatted and very short)

If anyone can get it to work as described on that page, then thank
you! Otherwise I think things need to be changed to make it possible.

   

http://nikic.lima-city.de/canvastest.html
This one satisfies at least the styling conditions (in Firefox and Chrome):
* The canvas has 80% width
* The canvas has 50% height (This one worked in Firefox only after 
setting height 100% on body and html. Strange...)

* Resizes when the browser resizes
* Is centered
I only couldn't figure out the  "Always draw a non-aliased pattern of 
lines" part in Firefox. I tried some stuff, but it didn't work.

Re: [whatwg] behavior

[Ian Hickson]

On Tue, 26 Jan 2010, Michael A. Puls II wrote:
> 
> Please see the note in the  element section. It has more 
> detailed info. The embed and applet elements have the old, less-detailed 
> note.

Yeah. It turns out that trying to make the paragraph that's in the 
 section fit the  and  sections makes it read 
poorly, which is why I phrased it differently. The gist is the same, 
which is what matters. It's only an informative note, after all.

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