- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 28 Dec 2008 11:38:07 +0000 (UTC)
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 <ian at hixie.ch> wrote:
>
> > > I'll add another case: the onafterprint event could be used in a
> > > "wizard"-style application where printing some document is step 3 of
> > > 10, for example. The application could proceed to the next step
> > > (not necessarily a different document) automatically without
> > > requiring a button that says "click here when done printing".
> > > That's a case that a media-specific stylesheet cannot handle.
> > > Automating tasks and reducing clicks are both high priorities in my
> > > development of web applications.
> >
> > Good use case!
>
> But breaks if the user does a print preview first, no? (The events fire
> in IE when doing print preview.)
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 now requires what you describe,
through the way things are defined.
> 4) The document's cookie context becomes the cookie context of the
> document of the currently executing script.
This is also defined in terms of the document's URL now, so it should just
work.
On Thu, 31 Jul 2008, Peter Kasting wrote:
> On Thu, Jul 31, 2008 at 2:31 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 30 Apr 2008, Peter Kasting wrote:
> > >
> > > Otherwise, if the element is not larger than the viewport, scroll
> > > such that the element is centered in the viewport (within the
> > > scrolling limits -- if the element is at the bottom of the page, it
> > > clearly can't be scrolled up to the middle of the viewport).
> >
> > As far as I can tell, as defined, browsers would be allowed to do all
> > this for scrollIntoView().
>
> I don't read the spec that way. The phrase "with the bottom of the
> element aligned with the bottom of the viewport" seems to rule out the
> possibility of other alignments such as suggested above.
>
> If you wish browser vendors to have the freedom to experiment here,
> perhaps a vague sentence such as "the user agent should scroll the
> element as necessary such that as much of it as possible is visible in
> the viewport" would suffice.
>
> My impression was that Firefox 3 changed scrollIntoView behavior
> precisely to comply with the detailed description currently in the spec.
>
> > It is effectively optional now. Horizontal scrolling is also required.
>
> Now I'm wondering whether I'm looking at the wrong version of the spec,
> since I don't see any of that.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#scrollintoviewstill
> seems to read a lot like I remember it...
The spec says "should", which basically means that given a good reason
(like wanting to experiment with a better user experience), the current
text can be ignored and something else done instead.
The text in the spec now describes what most browsers do, so I'm reluctant
to change it.
On Tue, 5 Aug 2008, Jonas Sicking wrote:
> Ian Hickson wrote:
> > On Tue, 5 Aug 2008, Jonas Sicking wrote:
> > >
> > > The concern I have with doing that is that document created through
> > > other means, such as .implementation.createDocument,
> > > XSLTProccessor.transformToDocument, DOMParser.parse, etc, probably
> > > should not be in the 'uninitialized' state. Especially the last two
> > > should return documents that is in the 'complete' state I would
> > > think.
> >
> > IE doesn't have any of those mechanisms. In IE,
> >
> > w(new ActiveXObject("Msxml.DOMDocument").readyState);
> >
> > ...returns "4", which isn't any of the values I expected.
> >
> > Right now the spec says that anything that doesn't go through a parser
> > will remain in the readyState == "loading" state forever. Is that a
> > problem?
>
> The one usecase I have heard for .readystate is to figure out if the
> document has had its onload event fired yet, or if one is coming later.
> In that scenario it would seem unexpected to return "loading" as no
> onload event is about to fire.
>
> > We could define that mechanisms that create a Document object without
> > an associated parser set it to "complete" if you want. I'm not sure
> > that that would be especially useful, although it would, I guess, be
> > somewhat more self-consistent.
>
> Yeah, i think so.
I've done this, but I'm going to need to revamp how we handle the XML
parser case in due course so it's not a perfect solution yet.
On Thu, 7 Aug 2008, Robert O'Callahan wrote:
> >
> > 1. If the title element is null, then a new title element must be
> > created and appended to the head element.
> >
> > 2. The children of the title element (if any) must all be removed. 3.
> > A single Text node whose data is the new value being assigned must be
> > appended to the title element.
>
> Steps 1 and 2 can fire mutation events and cause "the title element" to
> become null again. I suppose if that happens, the algorithm should stop,
> but the spec should say so.
My understanding is that mutation events are changing to a deferred
model, so this might become a non-issue. I've made a note of this in the
spec so that I don't forget to check it later.
On Wed, 29 Oct 2008, Weston Ruter wrote:
>
> I realized that the HTTP response headers exposed in the HTMLDocument
> interface are limited: referrer, cookie, lastModified, charset,
> characterSet.
>
> It would be very useful if a script could get *all* of the response
> headers, the raw entity body, and the HTTP status: basically it would be
> great if the HTMLDocument interface implemented a subset of of the
> XMLHttpRequest spec, namely the parts which have to do with the response
> (e.g. getAllResponseHeaders(), getResponseHeader(), status, and others
> which appear below).
Could you elaborate on the use case for this? What is the problem you wish
to solve that you can't solve right now that this would solve?
> The HTMLDocument interface already has a readyState property which
> XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
> onreadystatechange attribute.
.readyState on XHR and on HTMLDocument are quite different (one is a
string, e.g., the other a number). The onreadystatechange thing is an open
issue; at some point I need to go through and add all the events.
> If this subset were implemented on HTMLDocument, then scripts would be
> able to determine if the page if a 404 or get any other arbitrary
> information that is passed in the response header.
Surely a page knows if it is a 404.
On Wed, 29 Oct 2008, Weston Ruter wrote:
>
> Furthermore, having a HTMLDocument.responseXML would be useful in the
> case that an XSLT stylesheet outputs HTML, plain text, or something
> else; in such a case, it would be very useful to get the original
> responseXML. Note that I don't envision this responseXML being any sort
> of shadow DOM; I mean, if XSLT did transform the XML data, making a
> change to responseXML would not cause the XSLT engine to re-parse the
> updated responseXML. Maybe this would be useful, but it seems overly
> complicated.
Is this (needing access to the untransformed DOM) a problem people have?
On Thu, 30 Oct 2008, Weston Ruter wrote:
>
> I have an amendment to my proposal. There was a post on Ajaxian today
> about a "Language JSONP Service" which "calculates the users language
> based on browser headers". This seems like a terrible workaround since
> the Accept-Language header is sent from the same browser that the script
> is running in; a script shouldn't have to make an HTTP request just to
> find out what the browser's request headers are.
If the problem is finding out what people's preferred language is, then we
can certainly expose that more conveniently than exposing all HTTP
headers. Is that the problem we are trying to solve here?
We don't expose them currently, but we could expose one or more of:
navigator.browserLanguage
navigator.userLanguage
navigator.language
On Wed, 10 Dec 2008, Thomas Broyer wrote:
>
> First, those client-side properties give you one lang code only, which
> is clearly not enough for conneg. Let's say I have a GWT application
> available in dutch and english, where dutch is the "default language"
> (i.e. prefered over english). My navigator.language returns "fr", but my
> Accept-Language reads "fr-fr, fr, en". With navigator.language only, I'd
> have the dutch version, with Accept-Language I'd have the english one.
For content negotiation, we don't need an API as far as I can tell, we
need HTTP headers. We already have those.
> Second, these client-side properties return the UI language, which is
> different from the user-preferred language. FF3.1b2 is now available in
> many languages but before that, only english was available.
> navigator.language in this case would return "en", despite me having
> changed Accept-Language to "fr-fr, fr, en".
We could certainly expose more languages, though one wonders how reliable
that would end up being, given the rarity of users changing their
configurations at all.
On Wed, 10 Dec 2008, Weston Ruter wrote:
>
> Another use case would be getting the "Accept" header to detect if the
> client can be served XHTML.
Wouldn't the server be the one who would need to know that? And thus would
be able to know that by checking Accept directly?
Also, it's easy to check if the browser supports XHTML directly, without
having to defer to the Accept header, which might not list it.
On Thu, 27 Nov 2008, Garrett Smith wrote:
>
> It is often desirable to capture events on bubble and interrogate the
> EventTarget using a hasClassName function to see if it has a className
> that the program is concerned with.
>
> Assuming an - addCallback - function that acts as an adapter for
> addEventListener/attachEvent,
>
> addCallback(document, "mousedown", docMouseDown);
>
> function docMouseDown(ev) {
> var target = EventUtil.getTarget(ev);
> if(!hasClassName(target, "panelActuator") ) return;
> }
>
> The above code relies on a - hasClassName - function. These are
> widespread on the web and the practice is very common. It might be
> useful to have a native function that does the same thing.
On Thu, 27 Nov 2008, Anne van Kesteren wrote:
>
> HTML5 already has the functionality you request in form of the classList
> DOM attribute on HTML elements.
What Anne said.
On Thu, 25 Dec 2008, Philipp Serafin wrote:
> Ian Hickson schrieb:
> > On Thu, 18 Dec 2008, Philipp Serafin wrote:
> >
> > > I think it would be a good idea to spec this algorithm as well then.
> >
> > The algorithm I described is basically CSS' "shrink wrap" algorithm.
> > But we can't really require it, as it assumes that the OS has windows.
> > My desktop, for example, doesn't have resizable windows, it only has
> > tabs (I use the 'ion' window manager).
>
> Well, you could still phrase it something along the lines of "The size
> of a popup document's viewport SHOULD be calculated using the CSS shrink
> wrap algorithm... etc etc".
I don't see why it _should_, though. I mean, surely that's up to the UA.
Like I said, on my desktop machine, I wouldn't want that behavior.
> All I really just want is to make sure browsers don't use today's
> implentations. If you open a popup/modal dialog today and don't specify
> a size, you usually end up with an arbitrary default size or even a
> full-fledged second browser window the size of your screen - both pretty
> ill-fitted for the use-cases of showModalDialog() IMO.
I recommend filing bugs with the browser vendors. Or not using
showModalDialog(), which is probably even better. :-)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 28 December 2008 03:38:07 UTC