[whatwg] DOM-related and API-related feedback
On Sun, 8 Jun 2008, Ojan Vafai wrote: I can speak to the first (getNextFocusableElement). One case I have hit where this would be useful is a designMode iframe (in this case a rich-text editor). I wanted tab to go to the next focusable element, which was a different element depending on the context the editor is embedded in. There's currently no way to do that. It seems like this is something that should be left up to the user agent. After all, how is the Web page to know which key binding moves the focus normally anyway? If we were to provide this it seems what we'd have to do is provide an API that actually moves the focus (e.g. provide a focusNextElement() method and a focusPreviousElemnt() method), since the next focusable item might not even have a DOM node (e.g. the location bar) or it might be in another origin. But then what if the user agent doesn't do things using a cycle but instead uses directional focus management, like many phones? On Thu, 12 Jun 2008, Mike Wilson wrote: 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. As a user, I would find such behavior incredibly annoying. I've now specced window.focus() and window.blur(), but mostly as no-ops. I've noted that window.focus() could trigger a notification. 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. I don't see any reason to let the latter be done at all really. Lastly, I guess if deprecating window.focus() devs would start using myDummyElem.focus() instead, to achieve the same result? myDummyElem.focus(), as defined, doesn't affect system focus unless the window is already focused. On Mon, 9 Jun 2008, Simon Pieters wrote: On Fri, 06 Jun 2008 02:11:45 +0200, Ian Hickson i...@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.) True, though a page could work around that. On Fri, 13 Jun 2008, Adam Barth wrote: 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. Fixed now. 2) document.baseURI becomes the URL of the document of the currently executing script (not it's baseURI). This follows from the former and the definition of the base URL. 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.) Does the aliasing happen with all browsers? Without the aliasing, I believe the spec
Re: [whatwg] Semantics and related feedback
On 28/12/08 04:09, Ian Hickson wrote: I agree that conventions differ between media, but if the author wants to tweak the settings for each media, CSS and class values already exist to take care of this. That's true for authors only (the party least likely to want to tweak settings for other media and most likely to get them wrong). It's not true for default user agent stylesheets, it's not true for user stylesheets, and it's not true for user interfaces for controlling presentation. Realistically, I think one either has to say these differing conventions are not important enough to be represented on the web or that i doesn't actually deliver media independence on this front. i plus microformats might. -- Benjamin Hawkes-Lewis
[whatwg] script-related feedback
On Thu, 21 Aug 2008, Jonas Sicking wrote: Here is the list of elements that we *don't* execute scripts inside of in firefox: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148 i.e. iframe, noframes, noembed Everywhere else we do execute the script. The reason these elements ended up at the list is in bugs https://bugzilla.mozilla.org/show_bug.cgi?id=5847 https://bugzilla.mozilla.org/show_bug.cgi?id=26669 On Thu, 21 Aug 2008, Jo�o Eiras wrote: I kind of agree with iframe and noembed, but noframes ? noframes, IMO, it fairly legitimate, because you can have scripts providing fallback, or redirecting to another page. On Thu, 21 Aug 2008, Jonas Sicking wrote: Yes, we would presumably run scripts in noframes if we didn't have frame support. There is even a comment in the code that says that we should not check for noscript if we ever add the ability to turn off frame support. On Fri, 22 Aug 2008, Simon Pieters wrote: iframe, noframes and noembed are parsed as CDATA elements http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ciframe%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C%2Fiframe%3E so there can't be any script elements as children of those in text/html. In Opera and WebKit, the script executes in data:text/xml,iframe xmlns='http://www.w3.org/1999/xhtml'scriptalert(1)/script/iframe and it hasn't caused us any problems AFAIK. On Thu, 21 Aug 2008, Jonas Sicking wrote: Looks like firefox doesn't parse the contents of the iframe as markup either, but rather treat it as CDATA. Which makes me wonder why we ever look for iframes in the parent chain :) I suspect it's just remnants from when things worked differently, the check was put in in 1999 :) But the effect is that even in XHTML, like the example you're providing above, scripts in iframes don't execute. This was not intentional though given that this code was put in in 1999, before we had xhtml support. I have gone with the Safari/Opera behavior here rather than the Mozilla behavior. This means you can remove that check altogether, which should simplify the code a bit. :- On Thu, 30 Oct 2008, Keryx Web wrote: Webkit based browsers happily tries to parse scripts after the following tags: script language=javascript1.6 script language=javascript1.7 Even though neither Safari nor Chrome support those JavaScript versions. And it is not a matter of bugs, but lacking implementations. No browser runs script specified with: type=text/ecmascript;version=2.0 type=application/ecmascript;version=2.0 type=text/ecmascript;version=3.0 type=application/ecmascript;version=3.0 A. Should not the spec mandate that a browser must support a certain version of JavaScript if it tries to run it? It already does require this (though it is defined the other way around, in that the requirement to run the script is only reached if the script type is supported). B. Should the spec mandate that a browser must run a script that it de facto supports, e.g. ecmascript 3 in Firefox? I don't understand what this means. On Fri, 12 Dec 2008, Ojan Vafai wrote: I just went ahead and specced out the 'onbeforeunload' feature that most browsers support today that handles this case. If we're going for matching what browsers do, there's a number of cases (different in each browser) where the confirm doesn't popup. In Chrome, for example, if the beforeunload handler takes too long, we kill it and navigate away. Similarly, in Firefox, if the beforeunload handler hits the limit for script execution and the user stops the script, the beforeunload handler never fires. I've added a section that allows these behaviors. Not sure what the right language for that is. But developers try to do things like using beforeunload/unload to release locks, make server requests, etc. and it's just not a very reliable thing to do in any browser. It's really just useful for the quick prompt for the user as to things like unsaved changes. I haven't mentioned this in the spec, but I agree that it should be mentioned in the authoring guide. On Fri, 12 Dec 2008, Martin Atkins wrote: Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? In particular, the close tab and close window features, ideally along with things such as Back, Forward and Home should still be available. It'd have to block any page in the same unit of related browsing contexts, but otherwise yes. Chrome does this, mostly. IE8 probably too. This does of course create some tricky interactions where onbeforeunload is concerned. If I try to close the browser/tab and the page uses onbeforeunload to create a confirmation prompt, how does this interact with the confirmation prompt only being tab-modal? The spec now says you can disable scripting at
Re: [whatwg] Semantics and related feedback
On Sun, 28 Dec 2008, Benjamin Hawkes-Lewis wrote: On 28/12/08 04:09, Ian Hickson wrote: I agree that conventions differ between media, but if the author wants to tweak the settings for each media, CSS and class values already exist to take care of this. That's true for authors only (the party least likely to want to tweak settings for other media and most likely to get them wrong). It's not true for default user agent stylesheets, it's not true for user stylesheets, and it's not true for user interfaces for controlling presentation. Realistically, I think one either has to say these differing conventions are not important enough to be represented on the web or that i doesn't actually deliver media independence on this front. i plus microformats might. I believe I did say later in that e-mail (though maybe in not so many words) that there was no point trying to provide semantics as fine-grained as would be necessary to handle all these cases of media-specific conventions, because authors are unlikely to have the patience to actually use such markup correctly anyway. We already see people using em for things other than emphasis; I don't think providing even more fine-grained semantics would really help here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOM-related and API-related feedback
Ian Hickson wrote on 28 december 2008 12:38: On Thu, 12 Jun 2008, Mike Wilson wrote: 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. As a user, I would find such behavior incredibly annoying. I think you need to think about not only alien pages that want to do you harm, but also about web applications f ex on intranets that solve a complex task through the use of multiple windows. I've had users of the latter demand that we (the developers) raise windows automatically based on different events. Personally I'm not a fan of auto-raising windows (f ex MS Windows does it too often for my taste) but I think these users' use cases have been valid. I've now specced window.focus() and window.blur(), but mostly as no-ops. I've noted that window.focus() could trigger a notification. I read your updated text, and while it is great that you have added the notification stuff, I think removing focus's current behaviour is a hard legacy to break. Even good scripts would need to workaround it at times. I think UAs could be encouraged to handle focus like many popup blockers do; have a global setting to determine the default behaviour (system focus|notification|ignore) and then being able to override this setting for f ex selected sites or the current session. 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. I don't see any reason to let the latter be done at all really. I'm confused. I responded to this sentence in your previous mail: Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. but now you say that this should never be done (which I think is fine btw). What did I misinterpret? Best regards Mike Wilson
Re: [whatwg] script-related feedback
On , Ian Hickson i...@hixie.ch wrote: On Fri, 12 Dec 2008, Martin Atkins wrote: Could browsers handle confirm() and friends in such a way that they only block the contents of the tab, not the whole browser? In particular, the close tab and close window features, ideally along with things such as Back, Forward and Home should still be available. It'd have to block any page in the same unit of related browsing contexts, but otherwise yes. Chrome does this, mostly. IE8 probably too. That is a browser issue. Chrome and IE8 don't have it because they are multi-process. Opera never had the issue because processing is always divided between the UI and webpages. No spec should go into great lengths specifying how UI should behave and look, although it can make recommendations.
Re: [whatwg] DOM-related and API-related feedback
On Fri, 13 Jun 2008, Adam Barth wrote: 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.) Does the aliasing happen with all browsers? Test case: http://www.webblaze.org/tests/alias/ Browsers that alias: Firefox 3, Safari 3.1.2, Chrome. Browsers that do not alias: Internet Explorer 7, Opera 9.5.2 This looks like a Firefox-ism that I copied into WebKit. We added aliasing to WebKit because, without it, we failed a regression test. I'll investigate whether that test is based on a real web site. Jonas has previously said he thinks the aliasing is important for web compatibility. Jonas, do you know of actual web sites that will break if we follow the current HTML 5 text? Adam
[whatwg] Resolving a URL
Hey, Time to send some feedback on the resolve a URL dfn. Step 3 is (currently) If encoding is UTF-16, then change it to UTF-8.. Does this mean we literally change just encoding to UTF-16, and leave url verbatim, or are we meant to change url to UTF-8 too? This is currently ambiguous. Not changing url will cause issues later in a UTF-16 document. Step 12 replaces \ with /. IIRC WebKit does this for all URLs, not just those with a server-based naming authority (what's that anyway?). Also, earlier in the Resolving URLs section, there should probably be a ref. to XMLBASE. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] DOM-related and API-related feedback
On Sun, Dec 28, 2008 at 6:22 PM, Adam Barth wha...@adambarth.com wrote: On Fri, 13 Jun 2008, Adam Barth wrote: 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.) Does the aliasing happen with all browsers? Test case: http://www.webblaze.org/tests/alias/ Browsers that alias: Firefox 3, Safari 3.1.2, Chrome. Browsers that do not alias: Internet Explorer 7, Opera 9.5.2 This looks like a Firefox-ism that I copied into WebKit. We added aliasing to WebKit because, without it, we failed a regression test. I'll investigate whether that test is based on a real web site. Jonas has previously said he thinks the aliasing is important for web compatibility. Jonas, do you know of actual web sites that will break if we follow the current HTML 5 text? I don't know of any websites unfortunately. I've cc'ed Boris who might know. In general, if IE doesn't do it it seems unlikely that many sites depend on it. / Jonas
Re: [whatwg] DOM-related and API-related feedback
Jonas Sicking wrote: I don't know of any websites unfortunately. I've cc'ed Boris who might know. In general, if IE doesn't do it it seems unlikely that many sites depend on it. Agreed on the latter. On the former, it wouldn't be a problem for websites per se, but the aliasing needs to happen when a page whose origin is a globally unique identifier has an about:blank iframe. Or rather, the origin of the iframe needs to be the _same_ globally unique identifier. In Gecko this is implemented by simply using the same origin object for both. Note that in IE the security model around about:blank is pretty weird last I checked, so I'd want to see some pretty exhaustive tests before changing Gecko behavior in web-facing about:blank. -Boris
Re: [whatwg] Parsing, syntax, and content model feedback
On Thu, Dec 25, 2008 at 9:51 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: 2008/12/25 Ian Hickson i...@hixie.ch XMLHttpRequest was invented by Netscape, now it is a W3C Technical Report (I don't remember what maturity level). The same with so called DOM level 0 (now HTML5) No, sorry, that's not true. Garrett Giovanni
Re: [whatwg] accesskey attribute with display:none elements
On Fri, 28 Nov 2008 05:01:42 +1100, Olli Pettay olli.pet...@helsinki.fi wrote: On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote: Perhaps a *good* rationale could be, if you can't see the control, There are other modalities than just visual. Sure. But users generally expect the page to work the same dependent on usage, not dependent on their modality (which the page can't be sure of anyway). So, I stand up for standardizing the disallow accesskey activation for 'display:none' elements behaviour. So you're willing to break accesskeys on some websites. Note, I'm not very strongly supporting accesskeys on display:none elements, but breaking existing web sites doesn't sound good. In principle I think it makes good sense for accesskeys not to work on things that are disply:none. But in practice, I think Olli's argument (it ain't broke so lets not 'fix' it - especially in a way that breaks stuff) is the one that carries the most weight. 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: http://www.opera.com
Re: [whatwg] attribute media on script element
On Sat, 15 Nov 2008 08:18:25 +1100, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Nov 2008, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) This doesn't really work because media queries are supposed to change dynamically. The real solution here is a combination of XBL2 and a new API in the CSSOM-View draft (window.media). Hi Ian, I can see the value in this (but then, I also see the value in media types in styling - something it seems some browser makers are not really interested in), and I agree with David's concern that it can have some pretty costly implications. Can you explain why XBL2 is part of the solution here? It seems you have something in mind that I don't understand yet. thanks 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: http://www.opera.com
Re: [whatwg] attribute media on script element
On Mon, 29 Dec 2008, Charles McCathieNevile wrote: On Sat, 15 Nov 2008 08:18:25 +1100, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Nov 2008, Filippo Levizzani wrote: Would it be possible to have media attribute in the SCRIPT element? Addmitted vaues would be the same of STYLE element (all, screen, print, handheld ...) This doesn't really work because media queries are supposed to change dynamically. The real solution here is a combination of XBL2 and a new API in the CSSOM-View draft (window.media). I can see the value in this (but then, I also see the value in media types in styling - something it seems some browser makers are not really interested in), and I agree with David's concern that it can have some pretty costly implications. I don't really understand what you mean here. How are browser vendors not interested in media types in styling? What has costly implications? What implications? Can you explain why XBL2 is part of the solution here? It seems you have something in mind that I don't understand yet. Media-specific scripting is usually needed for media-specific presentation or widgets. XBL2 is a way to define widgets, and it can be bound in a media-specific way. Thus for instance one could create a set of widgets for different window widths, and they would dynamically be swapped in as the user changed the window size. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
