Re: [whatwg] When closing the browser
Ian Hickson schrieb: One option would be to have an attribute, say body logout=, Maybe link rel=logout href=... is more suitable? which causes the user agent to ping the site when the window is closed and there are no other windows open to the same origin. Of course this would break if the other window in question was open to a different page that didn't have the logout= attribute.. Maybe it should be invoked if there are no other pages open that have the same logout= attribute? Sounds ok to me. Server-side applications should probably implement that in a way such that just one session (identified by a session cookie or whatever) gets logged out -- in contrast to all sessions of a user. The user might be logged in using 2 different browsers and might want to log out in one browser but keep the session active in the second one. And I'd probably want a same domain policy for the logout ping be implemented in the browser. -- Philipp Kempgen
[whatwg] 5.12.3.7 Link type help
---cut--- 5.12.3.7 Link type help The help keyword may be used with link, a, and area elements. For link elements, it creates a hyperlink. ---cut--- Shouldn't that read For *a* elements, it creates a hyperlink.? Philipp Kempgen -- AMOOCON 2009, May 4-5, Rostock / Germany - http://www.amoocon.de Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --
Re: [whatwg] Thoughts on HTML 5
Ian Hickson schrieb: Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I'd say it _did_ work. :-) Philipp Kempgen
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson schrieb: On Tue, 25 Nov 2008, Julian Reschke wrote: The problem is that you'd basically have to duplicate the entire form, since login forms can be arbitrarily complex. If the bot has the username and password, why not also give it the username field name, password field name, and login script url? Just consider them part of the credentials. That works in theory, but doesn't scale. For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields Ugh. Philipp Kempgen
Re: [whatwg] Solving the login/logout problem in HTML
Julian Reschke schrieb: Ian Hickson wrote: For instance, we've been working on a search engine that scan internet sites that may require authentication. Configuring that login for each site would be a maintenance nightmare. Well for a piece of software of that scale, parsing the document using an off-the-shelf HTML parser and finding the first matching form element and then applying normal HTML semantics to get to the form fields seems like a pretty small task in comparison to the rest. Well, that's what we have been doing. I was looking forward where this could be used by somebody who isn't an expert (think Microsoft Webfolder client or Apple WebDAV FS driver), and where running an HTML parser (in the kernel?) would be problematic. So, on the other hand, if the login form is more complex than username + password, what is a bot supposed to do with it? I don't understand why it makes a difference what the form is like. It should apply whatever credentials it has been given -- whatever those might be, username/password, certificate, fake addressa and phone number, whatever, and submit the form. Just like a user. To do that, it would need to *capture* that information somewhere. I was assuming the whole point in the exercise was to avoid having to pop up an HTML based UI... PS: But even if it doesn't help authenticating without an HTML based UI, this could be useful because it allows non-interactive clients to understand that they're looking at a login form, not the real thing. Good points. There are circumstances where the client is not prepared to handle or parse HTML. However if the client is a human user you want a nice login page instead of the ugly basic authentication dialog. Philipp Kempgen -- http://www.das-asterisk-buch.de - http://www.the-asterisk-book.com Amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --
Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
[EMAIL PROTECTED] schrieb: [...] Please quote properly. Otherwise it's incredibly hard to follow the discussion. Thanks. Philipp Kempgen
[whatwg] OT: Re: Text APIs on canvas
Ian Hickson schrieb: I don't want to mislead implementators into thinking bitmap fonts are in any way an option in this day and age. Hey, 9 pt Monaco as a bitmap font is still my favorite font for programming, e-mail, shell, ... But I guess that's slightly off-topic for a discussion about SVG. :) Regards, Philipp Kempgen -- amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Let's use IT to solve problems and not to create new ones. Asterisk? - http://www.das-asterisk-buch.de Geschäftsführer: Stefan Wintermeyer Handelsregister: Neuwied B 14998
Re: [whatwg] Text APIs on canvas
fantasai schrieb: Ian Hickson wrote: The idea is that only scalable (vector) fonts should be used, since otherwise things will quickly look ugly. I've made the spec require this. Going forward the spec is likely to require effects such as adding text to paths, which will require vector data for all fonts used anyway. I don't want to mislead implementators into thinking bitmap fonts are in any way an option in this day and age. Just fyi... IIRC, Chinese and Japanese fonts often have to use bitmaps for smaller pixel sizes. Shrinking the vector wouldn't be clear enough for high-density characters: in many cases certain carefully-chosen strokes are left out in the smaller sizes in order to make it legible. I don't think a lovingly handcrafted 9px glyph would still be legible after rotating it according to the path - unless the path is just a straight horizontal line. Judging from information about Meiryo, it seems more recent font technology uses vectors + hinting to solve the same problem... but maybe it's something to keep in mind. afaicr fonts have used hinting for the last 15 years if not more so that's not some kind of new technology. Regards, Philipp Kempgen -- Asterisk-Tag.org 2008, May 26th/27th - http://www.asterisk-tag.org amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998
Re: [whatwg] Revised Plan for Server-sent DOM events
Dan Mosedale wrote: Anne van Kesteren wrote: - Continued problems of the 2 connection limit on HTTP server scalability Is there any realistic solution to this other than to use separate domains and have cross-domain working? Simply get rid of, or significantly raise, the limit? Standards work related to this probably belongs (and conceivably is already happening) in an HTTP protocol forum. I did some poking around recently, and browser behavior related to this limit is fairly varied, depending on context. You're talking about the default/standard behavior, right? In FF this value can be changed (network.http.max-connections-per-server etc.) - but telling from your e-mail address you probably already know that. :-) Regards, Philipp Kempgen
