Re: [whatwg] HTML5 frame navigation policy
On Tue, 29 Jan 2008, Collin Jackson wrote: On Oct 26, 2007 3:51 PM, Adam Barth [EMAIL PROTECTED] wrote: Collin Jackson and I have been looking at the frame navigation policy of various browsers and have a suggestion for improving the frame navigation policy in the HTML5 spec. As we understand the spec [1], it is stricter than IE7, Firefox 2, IE6, and Safari 3. Since Adam sent this original email, we've been working with browser vendors to deploy the Ancestor frame navigation policy in browsers. A description of this policy can be found at http://crypto.stanford.edu/frames/. By adopting this policy, HTML5 will match Internet Explorer, Firefox, and Safari. Done. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] postMessage support now in Firefox trunk, implementation issues, feedback, tests
On Wed, 30 Jan 2008, Jeff Walden wrote: The spec's incomplete or vague on a few points right now. The points I know where I forged new ground or think clarifications/explicit notes may be in order are: * event.domain/uri values in a rewritten about:blank document The spec seems to somewhat indicate that we should be using about:blank and as uri/domain right now, but that's fairly useless in terms of allowing postMessage in dynamically-created pages. This probably wants to change to reflect the document's origin/principal, and assuming things go the way most browsers have implemented it, this means those values are the same as for the opener of about:blank. This is tested in test_postMessage_special.xhtml. Note that there are two different tests of this behavior which change the document in slightly different ways, and Mozilla expects them to have the same results right now. Fixed. * event.domain/uri values for IDN URLs We use the Unicode-ized values of these, not the Punycode versions. (Actually, that's a lie -- what we use depends on whether the relevant TLD is whitelisted for non-punycode display or not, which is clearly the wrong behavior; at the moment I doubt this will be fixed for Firefox 3, sadly.) I think this is what authors would most likely expect, if not now then when IDN is truly widespread (when we'd be stuck with punycode if we were to choose it now), but the spec doesn't say anything about IDN yet. Fixed. [snip many other comments that either I've already replied to or that have been overtaken by events] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modal dialogs in HTML5
If I understand it correctly, the suggested sections and irrelevant
attribute would make dialogs work quite like current modal HTML
dialogs from various js libs (the latter making use of backdrops to
hinder access to original page content) as new content from the same
page is swapped into view in front of the original content.
The modality comes natural when the original content is swapped out
from view and only the dialog content is accessible.
Though, I wonder if these two cases are addressed by sections/
irrelevant:
1. See-through-view modality
Is it possible to pop a dialog on top of (while still showing) the
original content, but hindering interaction with it? (much like what
current js libs offer with their dialog classes)
2. Unload modality
Most modality discussed so far has been about the view modality, ie
disallowing the user from accessing the original page content until
the dialog has been dismissed. Browser modality may also be about
not letting the browser unload/reload the page until a dialog has
been dismissed (eg do you want to save before closing the window?).
Is there any way to force a user to respond to a modal dialog
section before unloading the page?
If not, ideally a generic modality feature could be added to assist
both sections and current style HTML dialogs in achieving this
unload modality.
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: den 27 april 2008 10:59
To: [EMAIL PROTECTED]
Cc: Web APIs WG (public)
Subject: Modal dialogs in HTML5
On Fri, 27 Apr 2007, Jon Barnett wrote:
On 4/26/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005, Karl Pongratz wrote:
I had a short look at the webforms and web applications
specification at whatwg.org, I didn't find anything
about modal and
modeless windows. If there is anything to improve for
html, xhtml,
xforms and compound documents, then, in my opinion, the first
missing feature that comes into my mind is the lack of
modal and
modeless windows.
I've now added window.open(), irrelevant=, and target= to the
specification, which should provide various ways of obtaining the
effect you're looking for. For example, with
irrelevant= you can
hide the content you want to disable, and force the
modal aspect of
the application to be responded to before reshowing the
other parts.
Can I ask how that would work with a dialog? Would it be like this?
myframeddocument.designMode = on;
mytoolbar.hyperlinkButton.onclick = function() {
myframeddocument.body.irrelevant = true;
var dialog = window.open(hyperlinkDialog.html);
// a dialog where the user may either enter a URL or choose
from a preset
list of pages on his site
dialog.onunload = function() {
processHyperlinkSelections();
myframeddocument.body.irrelevant = false;
}
}
Is that really the best way?
No, I meant everything within the one document, with
sections for each
part of the app, and all but the current section having
irrelevant=
set.
Would that keep dialog on top of the main browser window
until it's
dismissed?
You should only use one browser window ever, as a Web app author.
I used the WYSIWYG example because I think it's a good case where
authors really want some sort of modal dialog that's
synchronous in the
opener document's javascript. Is there a better way to handle that?
I'm also curious why the features argument of window.open
is supposed
to have no effect. That's something I can search the
archives for on
my own if it's been asked and answered.
Because none of the features that browsers support are things that
actually should be supported, as they are not things that
help the user.
On Fri, 27 Apr 2007, Thomas Broyer wrote:
If I correctly understood Ian's proposal, the best way
would be to not
use another window.
1. put the content of hyperlinkDialog.html within the current page
(or eventually load it within an iframe) and make it irrelevant=true
(let's call this the hyperlink editing section)
2. when you click the hyperlink toolbar button, make the
hyperlink
editing section irrelevant=false
3. when the OK or Cancel button inside the hyperlink
editing section
is clicked, do what's needed and switch the section back to
irrelevant=true
Pretty much.
On Sun, 27 Jan 2008, Karl Pongratz wrote:
You say:
Notwithstanding the features that make this possible, I
have to say that in
general Web applications on the Web should not be written
as if they are
desktop applications.
1.) We actually miss web application models. Do you know of
any where
they are defined, though some which don't have any quirks?
Application
models where the web browser back/next and reload button
doesn't harm
anything? Maybe its time to fix this
Re: [whatwg] HTML5 frame navigation policy
A couple points about Section 4.1.4: 1) The spec, as written, prohibits frame-busting. Test case: http://crypto.stanford.edu/~abarth/research/html5/frame-busting/ Browser behavior: * Internet Explorer 8 beta: Navigation allowed. * Firefox 3 nightly: Navigation allowed. * Safari 3.1: Navigation allowed. * Opera 9: Navigation allowed. Frame-busting is used by many sites, including the Yahoo sign-in page. The Yahoo sign-in page uses frame-busting to avoid showing it's trusted sign-in image while being framed by an attacker (who can overlay his own password field on top of Yahoo's). 2) The spec reads The browsing context B an auxiliary browsing context and either its opener browsing context is A or A is allowed to naviga e B's opener browsing context. This is redundant because if B's opener browser context is A, then A is allowed to navigate B's opener browsing context. 3) Consider the following set of frames. A opens X, which opens B. Now A attempts to navigate B. Test case: http://crypto.stanford.edu/~abarth/research/html5/transitive-opener/ Browser behavior: * Internet Explorer 8 beta: Navigation allowed (IE does not implement an opener restriction). * Firefox 3 nightly: Navigation denied. * Safari 3.1: Navigation allowed (Safari does not implement an opener restriction). * Opera 9: Navigation denied. The spec allows this navigation because it says A is allowed to navigate B's opener browsing context. Now, A is allowed to navigate X (by this rule), which means A is also allowed to navigate B (by a second application of this rule). I don't have access to the Opera source code, but Firefox's opener restriction computes just one level of recursion. Note the branch at http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#1991 and that the function passes PR_FALSE for the parameter aConsiderOpener when it calls itself recursively. Adam On Tue, Apr 29, 2008 at 2:11 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 29 Jan 2008, Collin Jackson wrote: On Oct 26, 2007 3:51 PM, Adam Barth [EMAIL PROTECTED] wrote: Collin Jackson and I have been looking at the frame navigation policy of various browsers and have a suggestion for improving the frame navigation policy in the HTML5 spec. As we understand the spec [1], it is stricter than IE7, Firefox 2, IE6, and Safari 3. Since Adam sent this original email, we've been working with browser vendors to deploy the Ancestor frame navigation policy in browsers. A description of this policy can be found at http://crypto.stanford.edu/frames/. By adopting this policy, HTML5 will match Internet Explorer, Firefox, and Safari. Done. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More ImageData issues
On 22/02/2008, Oliver Hunt [EMAIL PROTECTED] 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]
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 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.)
--
Philip Taylor
[EMAIL PROTECTED]
Re: [whatwg] link rel=icon width= height=
On Tue, Apr 29, 2008 at 6:52 PM, Ian Hickson [EMAIL PROTECTED] wrote: This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). Opinions? +1 :) FWIW, the reason we want this as opposed to just trying all the icons is that we want to be able to render a confirmation UI that contains the icon immediately, without having to wait for all the icons to download. - a
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: (With my rarely-used Google hat on:) The Gears team has an API that allows authors to specify a set of icons: http://code.google.com/apis/gears/upcoming/api_desktop.html They used a scripted API, but when I tried to get them to use a declarative API, they said that the main reason they used a scripted one is that the declarative options didn't have a way to specify dimensions. This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). Opinions? I think a way to specify multiple icons at different sizes is a good idea. However, I do not think width and height attributes sufficiently cover the available options. We need to be able to handle: 1) Scalable vector formats such as SVG or PDF. These work well at any size. On some Linux desktop environments, SVG is used as a native icon format. 2) Formats that include bitmaps at multiple sizes. These include the Windows native ICO format and the Mac OS X native ICNS format. At least for Mac OS X, the HI guidelines strongly recommend providing multiple sizes for best integration with the system UI. It is possible in theory for a UA to download multiple icons at different sizes and build a multi-size file, but more network transactions is less efficient. Therefore, I think it needs to be possible to specify multiple sizes, or to specify that an icon is scalable and thus usable at any size. I would suggest a sizes attribute which can take a list of sizes (with x as a width/height separator), or a keyword such as any or scalable to indicate a scalable format suitable for any size. link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Regards, Maciej
Re: [whatwg] link rel=icon width= height=
Hello, On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: [...] link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Couldn't this also be done as... link type=icon type=application/svg href=whatwg.svg link type=icon type=image/microsoft.vnd.icon width=16 height=16 href=whatwg.ico link type=icon type=image/microsoft.vnd.icon width=32 height=32 href=whatwg.ico link type=icon type=image/x-apple-icons width=16 height=16 href=whatwg.icns link type=icon type=image/x-apple-icons width=32 height=32 href=whatwg.icns link type=icon type=image/x-apple-icons width=64 height=64 href=whatwg.icns link type=icon type=image/x-apple-icons width=128 height=128 href=whatwg.icns link type=icon type=image/x-apple-icons width=256 height=256 href=whatwg.icns link type=icon type=image/x-apple-icons width=512 height=512 href=whatwg.icns link type=icon type=image/png width=59 height=60 href=whatwg.png Basically link'ing to the same icon more that once for each size it is good for. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg] link rel=icon width= height=
Ian Hickson [EMAIL PROTECTED], 2008-04-30 01:52 +: The Gears team has an API that allows authors to specify a set of icons: http://code.google.com/apis/gears/upcoming/api_desktop.html They used a scripted API, but when I tried to get them to use a declarative API, they said that the main reason they used a scripted one is that the declarative options didn't have a way to specify dimensions. This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). I notice the docs for the icons param of the Gears createShortcut() method describe four discrete sizes that all have the same height and width (An object containing one or more of these named properties: 128x128, 48x48, 32x32, 16x16...). So do UAs expect [EMAIL PROTECTED] icons to always have the same height and width, and if so should the HTML5 spec make it clear that their height and width should be the same? If [EMAIL PROTECTED] icons in practice actually always have the same height and width, it seems like just adding just size attribute (e.g., link rel=icon size=32 ...) could achieve the same effect. Or if we wanted to really get declarative, I guess another way to do it might be to have an icontype (or whatever) attribute with an enumerated list of values that describe the intended purpose of the icon (instead of its size). So, icontype=favicon or icontype=desktop -- or whatever terms describe what the various (de facto) standard sizes of icons are used for. Or if not that, maybe the value should just be an enumerated list of size names -- e.g., small, medium, large, x-large. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
