Re: [whatwg] Session Management
02-03-11 18:42:41 schreef Bjartur Thorlacius: On 3/2/11, Dave Kok upda...@davekok.net wrote: Op 02-03-11 13:16:11 schreef Bjartur Thorlacius: On 3/2/11, Dave Kok upda...@davekok.net wrote: Op 01-03-11 23:29:26 schreef Ian Hickson: On Thu, 25 Nov 2010, Dave Kok wrote: I am still faced with the fact that there is no way to clear the HTTP authentication credentials cache. To some extent that's up to the browser. It logs you in, it can offer the ability to log you out. You can also login using AJAX requests. [..] Application protocols (FTP, HTTP) can trigger authentication. Users can authenticate, and refuse to authenticate (e.g. by discarding credentials). What additional features do you need, and to serve what use cases? Unrelated, how authentication is triggered has nothing to do with when it is cleared. But after authentication has been triggered and the user has entered it credentials (or used credentials that are pre- filled by the UA) those credentials are cached for automatic reuse, so the user does not have to log in and log in over and over again. Very useful, we all love it. But at some point those cached credentials must be cleared so the UA triggers again a dialog to require the user to log in again (possible again pre-filling credentials from some store). It is the clearing I propose a site should be able to aid the UA in. This is not a simple thing as the site does not know the credentials, as it should. But it often does now when a session starts and ends. So when it can communicate this to the UA, the UA can use this info to clear credentials at the appropriate time. Rather then waiting when the user closes the window or manually clears credentials using a browser UI feature. Should a user be expected to do this? I beg to differ. When credentials have been entered, it may be feasible to cache them as long as they're valid. In fact, writing autologin daemons, renewing security tokens periodically, is on my to-do list. So what does your argument boil down to. Having a method that a site can communicate to a UA that a session starts and ends, means that a UA can not provide a feature to keep a user always logged in? And because this interests you such a feature should not be included in the spec? Even for those UA's that do not have such a feature or in which it is very much desirable to have such a feature. Isn't it simply more interesting to say that a site may communicate when a session starts and ends and that a UA behaves the way a user wants it to (or a developer of the UA, proxy or what not, designed it to do). Whether this means clearing credentials or not. As far as I am concerned all that a site needs to know about, is about a session. And all it should be able to do is tell the UA when it starts or ends. Does having such a feature make it impossible for you to implement what you intend to? Simple use case description: - user navigates to start page of site, no authentication required, site knows session starts and tells UA. - user follows link to other page on same site, requiring authentication, UA associates credentials with current session (if it exists) somewhere hidden in the background. - user follows link named logout for instance. Site knows session ends and tells UA. UA now clears credentials cached between You're suggesting that documents *should* duplicate UA functionality? So I can use inconsistent UIs specific to each site, rather than customizable UI that works with all sites? This is not a use case that should be catered to specifically. No no no, there is no duplication. A UA doesn't manage sessions. Sites manage sessions. All a UA does is cleanup when it knows sessionStorage, session cookies and cached credentials are not going to be used any more or when a user requests those to be cleaned. A site enters stuff in the sessionStorage and creates session cookies when it needs to. And if it hampers functionality of the site cleans these thing up so if the user wishes to end and start a new session without opening a new window it gets a clean session. The only thing which makes the session unclean is those credentials still hanging around somewhere. Personally I just don't understand why you aren't thrilled about having this feature. It sounds like you are very infested in HTTP authentication. If all sites where to use it this would definitely broaden your scope for what you are doing. I just don't see how having a form of session control added to the spec restricts a UA in anyway of providing any feature a user desires. Just because a site says: 'UA session ends', doesn't mean that the UA has to do anything. Only those things that are sensible for the user experience. And for those UA's for which it is sensible to clear cached authentication tokens, they can do so. For those for which it is not, those don't. I am just providing a rational for having session management and what it could do.
Re: [whatwg] Session Management
Op 02-03-11 22:11:48 schreef Roger Hågensen:
Method #3:
The server (or serverside script, like PHP or similar) sends the
following to the browser:
header('HTTP/1.0 401 Unauthorized');
header('WWW-Authenticate: Close realm=My Realm');
*PS! the auth stuff is much longer here obviously, this was just
to show the use of Close*
Note:
If Method 1 or 2 is used the browser should probably send the
following
to the server:
GET /private/index.html HTTP/1.1
Authorization: Close username=something
*PS! the auth stuff is much longer here obviously, this was just
to show the use of Close*
May I point out that the HTTP is outside the scope of the HTML5 spec.
Also the HTTP is stateless. This requires both parties keep state which
breaks the statelessness property of the HTTP. I, for one, prefer to
preserve the statelessness property of HTTP.
Re: [whatwg] set input.value when input element has composition string
Hi, Niwa-san. On 2011/03/02 15:30, Ryosuke Niwa wrote: On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp mailto:m_k...@ga2.so-net.ne.jp wrote: On Safari 5, even if textbox has IME composition string, text into textbox can be replaced by DOM/script. But other browser's behaviors are different, and this is no specification when textbox has composition string. Although IE, Chrome and Opera keep composition string after value is replaced by DOM, each behavior is different. This is the result for this test on each browsers. When textbox has IME composition string such as ABCDEFG, then script (textbox.value = 123;) is called, textbox becomes... 1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G). 2. 123 (composition string is removed). 3. ABCDEFG (ABCDEFG keeps composition state and caret is after G). Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is Chrome 10 and IE9. You must have tested Chrome improperly. We currently have a bug in Chrome. To see the bug, open the attached test and type nihao with Chinese IME on Windows or Mac. Then press down array key. The text is replaced by henhao but henha is still marked and looks as if I'm compositing henha but if I continue to type ma still with IME, then I observe that henhaomao is shown inside the input element. Once this bug is fixed, Chrome's behavior should match that of Safari 5. Do you think Safari's way (ex. 2) is right? I found some bugs on Chrome (and IE and Opera) when I test this, but I am not interesting about bugs. It is confused that each Web browser is different behavior for this . This is not good as interoperability. So I would like to decide the right behavior/specification when textbox.value = 'x'; that it has composition string. Also, some people says that it should not be canceled/removed even if value is changed by DOM. Because composition string is un-committed string. Niwa-san and folks, how do you think right design for this situation?? -- Makoto Kato
Re: [whatwg] Session Management
On 2011-03-03 10:44, Dave Kok wrote:
Op 02-03-11 22:11:48 schreef Roger Hågensen:
Method #3:
The server (or serverside script, like PHP or similar) sends the
following to the browser:
header('HTTP/1.0 401 Unauthorized');
header('WWW-Authenticate: Close realm=My Realm');
*PS! the auth stuff is much longer here obviously, this was just
to show the use of Close*
Note:
If Method 1 or 2 is used the browser should probably send the
following
to the server:
GET /private/index.html HTTP/1.1
Authorization: Close username=something
*PS! the auth stuff is much longer here obviously, this was just
to show the use of Close*
May I point out that the HTTP is outside the scope of the HTML5 spec.
Also the HTTP is stateless. This requires both parties keep state which
breaks the statelessness property of the HTTP. I, for one, prefer to
preserve the statelessness property of HTTP.
Please appreciate the notion that HTML5 is broader then just browsing
the internet. - Dave Kok
And indeed it is. HTTP Authentication (especially Digest) is far from
stateless,
it's state chances with every single nonce number change.
It's basically a constant (but very cheap cpuwise)
handshake/hmac/diffie-hellman agreement.
Also if you are thinking about the HTTP status codes, those are beyond
stateless,
but if you insist, then simply re-use the 403 with some minor tweaks so
it acts as a logoff,
because re-using 401 would break the statelessness as you say.
I'm surprised you advocate ajax/XMLHttpRequest and allow to close from a
form,
that would open up to some security issues.
The beauty of HTTP Digest Authentication is that the password is never
sent as plaintext or in any form that can compromise the user's password.
Only the user themself (and thus indirectly the browser) or the server
should be able to initiate a session close of Auth Digest,
allowing it to close from a script is just bad, and... dare I say it,
counter to the statelessness of HTTP *laughs*
At least we agree on one thing, that where HTTPS is not available or
where the site owners have either not discovered or is too lazy or
unable to take advantage of StartSSL.com which is free,
then HTTP Digest Authentication should almost be a requirement for any
site that need login credentials. (like forums, shops etc.)
Funny how many stores only pull out the HTTPS stuff when paying for
things you buy (or use a specialist service), but not at all when you
log in to your account with them otherwise. *sigh*
Heck, I even have https on my own little site, my hoster provided the ip
for free, they set up the certificate etc, for free, excellent service.
(I only pay the hoster a small yearly fee, domeneshop.no for you
Norwegians out there)
and combine that with startssl.com and my total cost of securing the
communication with my site should I ever need it or others need
it??? PRICELESS, since it was absolutely free, not a single cent paid.
But... a lot of web hotels or hosters out there do not allow you to do
SSL or it costs extra, or they can not give you a ip or it costs extra,
and, and, and.
So I have sympathy for those unable to. but hey with the CA that
provides free domain/server certs there is no excuse if you ARE able to,
and programmingwise it's less work too, Auth Digest needs some extra
massaging from PHP to work nicely in a integrated way but even then
the logout issue still exist (and even if you log out the sie is still
spammed by the browser with login credentials all the time)
I've never really worked with the Apache auth_digest stuff, but it's
probably even more restricted than doing it yourself via PHP.
And don't forget that you complain that my suggestions messed with HTTP
which HTML5 had no business to mess with,
yet you yourself suggested XMLHttpRequest and some ajax stuff to
close/end a HTTP authentication?
This already proves that HTML5 isn't just HTML + CSS + Javascript + lots
of other stuff, but we can also add + HTTP
Now if this Auth Digest is so important for web apps, then shouldn't
WHATWG work together with (um what is the HTTP group called?)
--
Roger Rescator Hågensen.
Freelancer - http://www.EmSai.net/
Re: [whatwg] set input.value when input element has composition string
On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote: Hi, Niwa-san. On 2011/03/02 15:30, Ryosuke Niwa wrote: You must have tested Chrome improperly. We currently have a bug in Chrome. To see the bug, open the attached test and type nihao with Chinese IME on Windows or Mac. Then press down array key. The text is replaced by henhao but henha is still marked and looks as if I'm compositing henha but if I continue to type ma still with IME, then I observe that henhaomao is shown inside the input element. Once this bug is fixed, Chrome's behavior should match that of Safari 5. Do you think Safari's way (ex. 2) is right? In short, yes. It is confused that each Web browser is different behavior for this . This is not good as interoperability. So I would like to decide the right behavior/specification when textbox.value = 'x'; that it has composition string. Also, some people says that it should not be canceled/removed even if value is changed by DOM. Because composition string is un-committed string. It seems that the correct behavior depends on the semantics. Say I have typed a text 你好, then I decided to add 们 between 你 and 好 so I put the caret / insertion point between the two and start typing men on IME. At this point website randomly replaces the entire value by Hello. In that case, as a user, I wouldn't expect to have my uncommitted string men after Hello because semantically speaking, my greeting message in Chinese has entirely been replaced by one in English. There's no point in adding men at this point. On the other hand, if I had just typed 你 and website replaced the value by 你们 as I typed hao on IME, then having the uncommitted text after 你们 makes sense and I'd like to keep the text because then I can just commit my text to obtain 你们好. - Ryosuke
Re: [whatwg] Session Management
Op 03-03-11 12:17:22 schreef Roger Hågensen:
On 2011-03-03 10:44, Dave Kok wrote:
Op 02-03-11 22:11:48 schreef Roger Hågensen:
Method #3:
The server (or serverside script, like PHP or similar) sends the
following to the browser:
header('HTTP/1.0 401 Unauthorized');
header('WWW-Authenticate: Close realm=My Realm');
*PS! the auth stuff is much longer here obviously, this was
just
to show the use of Close*
Note:
If Method 1 or 2 is used the browser should probably send the
following
to the server:
GET /private/index.html HTTP/1.1
Authorization: Close username=something
*PS! the auth stuff is much longer here obviously, this was
just
to show the use of Close*
May I point out that the HTTP is outside the scope of the HTML5
spec.
Also the HTTP is stateless. This requires both parties keep state
which
breaks the statelessness property of the HTTP. I, for one, prefer to
preserve the statelessness property of HTTP.
Please appreciate the notion that HTML5 is broader then just browsing
the internet. - Dave Kok
And indeed it is. HTTP Authentication (especially Digest) is far from
stateless,
it's state chances with every single nonce number change.
It's basically a constant (but very cheap cpuwise)
handshake/hmac/diffie-hellman agreement.
Also if you are thinking about the HTTP status codes, those are beyond
stateless,
but if you insist, then simply re-use the 403 with some minor tweaks
so
it acts as a logoff,
because re-using 401 would break the statelessness as you say.
I'm surprised you advocate ajax/XMLHttpRequest and allow to close from
a
form,
that would open up to some security issues.
The beauty of HTTP Digest Authentication is that the password is never
sent as plaintext or in any form that can compromise the user's
password.
Only the user themself (and thus indirectly the browser) or the server
should be able to initiate a session close of Auth Digest,
allowing it to close from a script is just bad, and... dare I say it,
counter to the statelessness of HTTP *laughs*
At least we agree on one thing, that where HTTPS is not available or
where the site owners have either not discovered or is too lazy or
unable to take advantage of StartSSL.com which is free,
then HTTP Digest Authentication should almost be a requirement for any
site that need login credentials. (like forums, shops etc.)
Funny how many stores only pull out the HTTPS stuff when paying for
things you buy (or use a specialist service), but not at all when you
log in to your account with them otherwise. *sigh*
Heck, I even have https on my own little site, my hoster provided the
ip
for free, they set up the certificate etc, for free, excellent
service.
(I only pay the hoster a small yearly fee, domeneshop.no for you
Norwegians out there)
and combine that with startssl.com and my total cost of securing the
communication with my site should I ever need it or others need
it??? PRICELESS, since it was absolutely free, not a single cent
paid.
But... a lot of web hotels or hosters out there do not allow you to do
SSL or it costs extra, or they can not give you a ip or it costs
extra,
and, and, and.
So I have sympathy for those unable to. but hey with the CA that
provides free domain/server certs there is no excuse if you ARE able
to,
and programmingwise it's less work too, Auth Digest needs some extra
massaging from PHP to work nicely in a integrated way but even then
the logout issue still exist (and even if you log out the sie is
still
spammed by the browser with login credentials all the time)
I've never really worked with the Apache auth_digest stuff, but it's
probably even more restricted than doing it yourself via PHP.
And don't forget that you complain that my suggestions messed with
HTTP
which HTML5 had no business to mess with,
yet you yourself suggested XMLHttpRequest and some ajax stuff to
close/end a HTTP authentication?
This already proves that HTML5 isn't just HTML + CSS + Javascript +
lots
of other stuff, but we can also add + HTTP
Now if this Auth Digest is so important for web apps, then shouldn't
WHATWG work together with (um what is the HTTP group called?)
--
Roger Rescator Hågensen.
Freelancer - http://www.EmSai.net/
Hmm, within the scope of this feature request I am not advocating AJAX.
Just mentioned it as it can be used to login, see XMLHttpRequest.open.
It allows for a username and password to be passed in. Personally
however I prefer to let the UA handle this. Please note that at
XMLHttpRequest.open level nothing is known of HTTP or whether HTTP-
basic or HTTP-digest is used. To me this is an issue to be solved at
a layer lower then HTML5. And whether HTTP, FTP or some other protocol
is used to transfer data and do authentication it pretty much outside
the scope of my feature request. Also I didn't suggest using AJAX to
terminate the session. Read the full thread.
As to whether HTTP is stateless or not,
Re: [whatwg] Proposal for canvas src to allow images with structured fallback
On Wed, 02 Mar 2011 19:56:54 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: Thoughts on the problem or the proposed solution presented here? Why not use object? It already works and avoids overloading canvas for something it was not designed for. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Session Management
Here is a more formal proposal for Session Management. Hoping to get more traction. SCOPE The proposal is restricted solely the HTML5 spec. Though in the rational HTTP and authentication are mentioned as by example. INTERFACE This proposal requests for an new interface to be added to HTML5 usable from script. The interface is currently defined on the window global object. The naming is chosen so it seems natural to co-exist with sessionStorage. Prototype: window.sessionStart([string path = /, [boolean auto_end = false]]); The session start function should indicate to the UA that a new session is requested by the author for the current browsing context. From this point forward any session data should be associated with this session. However this is only done for documents loaded from the same origin or if a path is supplied for that path and sub paths of that path within the current origin. The auto_end argument may be supplied if a session should automatically end when the user navigates away from documents within the origin[/path]. Prototype: window.sessionEnd([boolean clearHistory = false]); The session end function should indicate to the UA that the current session is no longer valid. The UA can now stop associating session data with this session and unreference any session data associated with this session. The clearHistory parameter requests the UA, if true, to clear any documents within the back/forward history that have been loaded between session start and session end. UA's are only encouraged to do this for documents that required authentication and for which re- authentication is required after sessionEnd. This to prevent unauthorized access to cached documents by using the back/forward functionality to access information that would otherwise require authentication. Session data: What a UA considers session data in the context of this proposal is for a UA to decide but at minimal it is required to include data stored in the sessionStorage and cookies created through the document.cookie interface without expiration and any credentials supplied through the XMLHttpRequest.open function if the UA manages these. Additionally a UA is encouraged to include any cookies received without expiration from any source especially when made available through the document.cookie interface pertaining to the current origin[/path]. Any credentials that are cached for documents within origin[/path] and additional resources referenced by these documents whether or not within the origin[/path]. But only if the UA marks these for auto cleaning when the UA itself terminates. Ending sessions A UA is never required to wait until the sessionEnd is called before it ends a session and cleans associated data/state. But is encouraged not to selectively clean session data/state while sessionEnd has not been called. In others words all or nothing is preferred. A session is automatically ended when a current browsing context is closed. A UA may also have additional methods to force a session to end. RATIONAL The rational of this feature is to provide an easy method to clean session data/state after it is no longer required. How and when session data is cleaned when sessionStart is never called is not specified by this proposal. Implementers are encouraged to ignore any calls to sessionEnd if sessionStart has never been called. They may off course emit a warning/notice to aid an author in debugging. Basic usage scenario: 1. The user has navigated to a document and follows a link on which the author registered a onclick event and the event handler calls sessionStart. The UA now creates a new session, event handler ends and the UA loads the indicated document. If this document is within the scope of the session and authentication is required and no prior credentials exists, it gathers these credentials either from an external source or from the user and associates these with the session if it intends to dispose of these automatically when the UA itself terminates. 2. The user reads, clicks, types and follows links to other documents within the same origin[/path]. Possibly causing additional session data to be associated with this session. 3. The user follows a link on which to author registered a onclick event handler. The event handler calls sessionEnd. The UA now unreferences any session data associated with the session, event handler ends and the UA loads the document indicated by the link. On a side note this may very well be superior to a UA UI logout button. As the author can also specify a URL to go to after the session has ended. A UA UI logout button may not be able to do this in a meaningful way. What if's: 1. the user follows a link, clicks on a bookmark or enters a URL outside the origin[/path] for the current session. If auto_end was set to true. The session is ended as in step 3 of above scenario. 2. a session has been started with
Re: [whatwg] Proposal for separating script downloads and execution
On 3/3/11 5:20 AM, Henri Sivonen wrote: Are there the known to be pages that users frequently encounter that create and set src on a large number of script nodes without inserting them? Not known to me, no. I've seen pages that create lots of scripts (one per each dynamic action they want to do), of course. Or is this a theoretical concern about accidental resource exhaustion? More this, yes. Is the expectation that IE is safe because the accident happens on a sniffed branch that IE doesn't get? No, IE is safe because it coalesces the script loads in weird ways as discussed earlier in this thread. (I still quite like the idea of starting fetch upon setting .src and making insertion trigger evaluation. The idea of adding an execute() method scares me. Mainly because having an execute() method is so radically different from how things have worked so far and having insertion execute degrades gracefully(ish) in existing browsers.) I admit the graceful degradation argument is pretty tempting -Boris
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On 3/4/2011 3:53 AM, Aryeh Gregor wrote:
On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamirbret...@yahoo.com wrote:
In any case, spans with inline styles are much less likely to conflict with
other styling
I'm not sure what you mean by this. Functionally, in what way is
span style=font-style: italic less likely to conflict with other
styling thani, for instance? Possibly some authors do things like
i { color: green }, but they might do the same for span as well --
either seems equally unlikely to me.
Since span is meant to be a generic container with no inherent meaning
or formatting of its own (except being understood as being of inline
display), formatting a span without reference to class would be a pretty
broad stroke to paint, whereas styling an i (or em) would be
reasonably targeted. The only problem is that the advantages for styling
specificity which formatting tags offer are the same reasons why they
will more likely conflict when placed in another document. I think the
nicest solution would be span class=italic
style=font-style:italic;, but I don't know that the need to export
contents for external style usage is one worth complicating the markup
even further for everyone using it.
If one wishes to allow convenient export of the internally generated mark-up
for the sake of the user (e.g., to allow them to copy the markup for use on
their own site), it is nice for there to be choice at least between
non-formatting-committal (semantic) markup and non-semantically-committal
(formatted) mark-up
The commands we have are clearly presentational. E.g., we have an
italic command, and don't have emphasize or citation or
variable commands. If there were demand for it, semantic commands
could be added, but currently I'm assuming the use-case is only
presentational markup. If someone would like to argue that there's
substantial author demand or implementer interest in adding semantic
commands, we could do that, but they'd have to be separate features,
and we'd still have to deal with the commands that are presentational
only.
Personally, I'm not sure why there needs to be the redundant API with
insertHTML in the first place, if insertHTML can be standardized (maybe
with a removeHTML to target specific inserted tags?), so I don't see a
need for adding the semantic ones on top of that.
On Thu, Mar 3, 2011 at 12:51 AM, Roland Steiner
rolandstei...@google.com wrote:
Paraphrasing Julie's point
from our original exchange: you want to be consistent to make it easy to
hand-edit the resultant HTML (by the user, say), or for server-side
post-processing. For these purposes pure markup is often easier. OTOH, in
general, styles are more powerful.
I get the hand-editing argument.b is much nicer to hand-edit than
span style=font-weight: bold, and also fewer bytes. But why would
anyone wantspan style=font-weight: bold? Styles are more
powerful in general, but that's not a reason to prefer them in the
specific cases where they aren't more powerful.
In relation to strong, the reason is simply to avoid committing that
the usage of bold is for strong text. What is the practical use of
using strong/? Besides possible clarity in code, for richly semantic
documents, akin to the detailed level of markup present in TEI documents
used for marking up classical texts and the like, a browser user (or
programmer) can shape XQueries (or jQueries)--directly or by a
user-friendly wrapping GUI--which selectively extract that information.
If one wishes to find all passages in a work of Shakespeare where there
was indication in the original that there should be strong emphasis, one
can make a single elegant (and semantic) query which grabs that
information, while silently ignoring the span
style=font-weight:bold; (or b) tags which were instead used to
provide styling of say unmeaningful but bolded text in say the imprint
or wherever. (The reason to use span over b, on the other hand, is
simply to avoid the tag being at least semantically unamenable to
alteration by the designer given its always being assumed to be tied to
boldness by its use of b. )
Granted, a user or application might actually wish to search for text of
a particular formatting rather than a particular meaning, but if they
are not distinguished, only the former is possible.
Brett
[whatwg] Redirect handling for audio video
Hi, I was looking at the resource fetch algorithmhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resourcesection and fetching resources http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetch sections of the HTML5 spec to determine what the proper behavior is for handling redirects. Both YouTube and Vimeo do 302 redirects to different hostnames from the URLs specified in the src attribute. It looks like the spec says that playback should fail in these cases because they are from different origins (Section 2.7 Fetching resources bullet 7). This leads me to a few questions. 1. Is my interpretation of the spec correct? Sample YouTube Vimeo URLs are shown below. YouTube : src : http://v22.lscache6.c.youtube.com/videoplayback? ... redirect : http://tc.v22.cache6.c.youtube.com/videoplayback? ... Vimeo : src : http://player.vimeo.com/play_redirect? ... redirect : http://av.vimeo.com/05 ... 2. What about http: - https: redirects? Some content is required to be delivered only via https and this sort of redirect enforces that but isn't really a different origin. 3. If my interpretation of the spec is correct, are there proposals to change this or other specs that allow content providers to signal that these different hostnames actually represent the same origin. Thanks for your help, Aaron
Re: [whatwg] Improvement of the Application Cache
Sounds like there are at least two feature requests here... 1) Some way of not adding the 'master' entry to the cache. This is a common feature request, there's another thread about it specificially titled Application Cache for on-line sites. 2) The ability to add(), remove(), and enumerate() individual urls in the appcache. Long ago, there were interfaces on the appcache drawing board to allow that. They got removed for a variety of reasons including to start simpler. A couple of years later, it may make sense to revisit these kind of features, although there is another repository also capable of storing ad-hoc collection of resources now (FileSystem), so i'm not sure this feature really needs to be in the appcache. @Hixie... any idea when the appcache feature set will be up for a growth spurt? I think there's an appetite for another round of features in the offline app developers that i communicate with. There's been some recent interest here in pursuing a means of programatically producing a response instead of just returning static content. On Wed, Mar 2, 2011 at 7:40 AM, Edward Gerhold edward.gerh...@googlemail.com wrote: Hello, i would like to suggest an improvement for the Offline Web applications. Problem: I´ve found out, that i can not Cache my Joomla! Content Management System. Of course i´ve read and heard about, that the application cache is for static pages. But with a little change to the spec and the implementations, it would be possible to cache more than static pages. I would like to cache my Joomla! system. To put the scripts, css and images into the cache. I would like to add the appcache manifest to the index.php file of the Joomla Template. What happens is, that the index.php is cached once and not updated again. I can not view new articles. The problem is, that i can neither update the Master File, nor whitelist it. And this is, what my request or suggestion is about. I would like to whitelist the Master file, where the appcache manifest is installed in. Or i would like to update this file, or any file else, i would like to update, on demand. If there is any possibility, to do that already, please tell me. But i think that is not the case. Caching the CMS by making it possible to update or to whitelist certain files, the always dynamic frontpage or /index.php, would be the hammer to nail the board on the storage. Rules: The things, which should be considered are: *To allow to fetch the Master file, e.g. index.php* *in Joomla! over the NETWORK,* while any other file in the manifest get´s fetched or cached like before. Which is the most important for me, to get Joomla! into the cache. Javascript: For the script i would like to add *applicationCache.updateMaster()*, which forces the browser to fetch the file again. I think, this is impossible today, to update exactly this file. For the function, i could add a button to my page, to let the user choose to update the file. The second function would be *applicationCache.updateFile(url)*, which could be triggered by a button and script, too. I could let the user update certain articles. With that i would like to suggest* applicationCache.addToCache(url)* to add files manually or programmatic, which can not be determined by the manifest. Urls like new articles (*), i would like to read offline. I would like to add them to the cache, if the link appears, maybe on the frontpage. I would have to add the manifest to the CMS anyways, so i could add a few more functions to the page, of course. * applicationCache.removeFromCache(url)* should be obvious and helpful with the other functions. Good would be, to be able to iterate through the list of cached objects and even the manifest, with the update, add, remove functions, it would be very useful to work with the filenames and parameters. [(*) I could let the user decide wether he wants to download my mp3 files to the appcache or not, and fulfill the wish with the javascript functions. Maybe he´s got no bytes left or wants only the lyrics.] Conclusion: The application cache is very powerful. But it is very disappointing, that it is only useful for static pages. With a little improvement to the Offline Web applications chapter, and of course to the browsers, it would be possible to cache any Content Manager or dynamic page. And that would let the appcache become one of the most powerful things in the world. I could read my Joomla! offline, could update the cached files, if i want to, on a click or if the cache expires. I could let the half of the CMS load from the cache. But for that, the index.php, where the manifest is, has to be updateable. Correct me, if i am wrong. But this is not possible today, the master file can not be influenced. And there is no expiration or a possibility to update or manipulate the cache and even no way to find out which files are cached, what would let me/us have
Re: [whatwg] Proposal for separating script downloads and execution
So, I'm just curious, what do the participants of this thread (and Ian, specifically) feel is the most productive next step? We have 3 or 4 proposals that have all garnered various support. We've had at least one browser-developer informing us on concerns with various aspects of each. I have, at several times throughout this thread, summarized both pros and cons for my proposal. I would still like to see the same fairly done for the other proposals, so we could get a succinct statement of where each stands. Without simple summaries, it feels like the confusion of this thread has just overtaken the process and made it more cumbersome than its worth. At one point in the thread, it felt like there was some trend toward convergence, which seemed promising for progress. However, at this point, it seems like the more discussion we have, the more divergence we find. Is it time for this issue to be referred to some formal or informal working group committee to narrow the field? Is it time to just do some sort of democratic voting? Or are the disagreements over the 3-4 proposals simply too much for any progress to be made at this time? --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On Thu, 3 Mar 2011, Kyle Simpson wrote: So, I'm just curious, what do the participants of this thread (and Ian, specifically) feel is the most productive next step? We have 3 or 4 proposals that have all garnered various support. We've had at least one browser-developer informing us on concerns with various aspects of each. As with all other feedback on the spec, at some point I will take all the e-mail on the topic, read it, throw away any e-mail repeating previously-made points or just stating support without reasoning, and then reply, making any appropriate changes to the specification. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On Thu, Mar 3, 2011 at 4:03 PM, Brett Zamir bret...@yahoo.com wrote: Since span is meant to be a generic container with no inherent meaning or formatting of its own (except being understood as being of inline display), formatting a span without reference to class would be a pretty broad stroke to paint, whereas styling an i (or em) would be reasonably targeted. Perhaps, but both are likely to be very rare, especially where execCommand is typically used. I don't think this is enough of a justification for all the complexity of styleWithCSS unless you can find specific real-world cases where it would cause significant problems. I think the nicest solution would be span class=italic style=font-style:italic;, but I don't know that the need to export contents for external style usage is one worth complicating the markup even further for everyone using it. I'm pretty sure it's not. Personally, I'm not sure why there needs to be the redundant API with insertHTML in the first place, if insertHTML can be standardized (maybe with a removeHTML to target specific inserted tags?), so I don't see a need for adding the semantic ones on top of that. insertHTML just overwrites the entire selection with the given HTML, deleting its contents. You can't reliably use it to wrap text in an inline element, unless you write all the extremely complicated logic to do so yourself, in which case you may as well skip execCommand() and use DOM methods. In relation to strong, . . . I'm definitely not going to have bold create strong. It will create either (most likely) b, or (less likely) font-weight: bold. (The reason to use span over b, on the other hand, is simply to avoid the tag being at least semantically unamenable to alteration by the designer given its always being assumed to be tied to boldness by its use of b. ) Can you give a specific case where this might be a problem? If you're already altering the document, I'm having trouble seeing how it would be harder to alter b than span style=font-weight: bold. Altering the first seems much easier, since you can grab it with getElementsByTagName() and so on, without having to delve into CSS.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Great discussions!
On Fri, Mar 4, 2011 at 4:53 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir bret...@yahoo.com wrote:
Maybe the use of non-CSS mode was for backward-compatibility with earlier
versions or for easier overriding of styling in the target document
(e.g.,
b {color:red;}).
Using CSS might have been added by Mozilla since [etc. . . .]
This might or might not be the historical reason, but I'm really more
interested in the future: should the spec support this option, or
should we recommend that everyone just drop it? What are reasons that
we should keep it in the spec?
Backward compatibility. I suspect that there are many web contents that
depend on styleWithCSS available on WebKit / Gecko.
data:text/html,!doctype html
div style=font-weight: lighter contenteditable=true
pHello
/div
div style=font-weight: lighter contenteditable=true
pHello
/div
script
document.execCommand(styleWithCSS, null, true);
getSelection().selectAllChildren(document.querySelector(p));
document.execCommand(bold, null, null);
document.execCommand(styleWithCSS, null, false);
getSelection().selectAllChildren(document.querySelector(div + div p));
document.execCommand(bold, null, null);
getSelection().removeAllRanges();
/script
In Firefox/Chrome, first Hello is bold, second is not.
That just sounds like a bug. I admit that many execCommand implementations
are buggy but I don't think that'll no way justify dropping a
feature depended by web contents.
If one wishes to allow convenient export of the internally generated
mark-up
for the sake of the user (e.g., to allow them to copy the markup for use
on
their own site), it is nice for there to be choice at least between
non-formatting-committal (semantic) markup and non-semantically-committal
(formatted) mark-up
The commands we have are clearly presentational. E.g., we have an
italic command, and don't have emphasize or citation or
variable commands.
I'm not sure. IE used to use b for bold, i for italic and so forth but now
it uses strong and em respectively. And I'm sure there was a strong
motivation to do so given b and i are deprecated in HTML4. And you must
realize that browsers need to be able to remove em, strong, other
non-presentational elements added by IE, and style spans added by Gecko and
WebKit when removing or applying styles for the backward compatibility.
Because not being able to remove those elements result in not being able to
apply style properly.
On Thu, Mar 3, 2011 at 12:51 AM, Roland Steiner
rolandstei...@google.com wrote:
But how do you know what is the desired result?
I'm assuming that the desired result is make the selected text
bold/italic/purple/etc.. After all, that's how the commands are
named, it's how they're described in browser documentation, and it's
the only thing they do consistently between browsers. bold creates
strong, b, or span style=font-weight: bold depending on the
browser, and the only thing those have in common is presentation.
Again, each browser needs to recognize all of that as equivalent. Or
otherwise, it fails to remove styles added by other browsers. Also note
that b and i have semantic meanings and aren't purely presentational in
HTML5 (after all, that was the justification to add them back).
I get the hand-editing argument. b is much nicer to hand-edit than
span style=font-weight: bold, and also fewer bytes. But why would
anyone want span style=font-weight: bold? Styles are more
powerful in general, but that's not a reason to prefer them in the
specific cases where they aren't more powerful.
I agree that style spans are verbose and probably undesirable. However, how
do you specify font size, font family, and font color? WebKit currently
uses font element when styleWithCSS=false. But font element is deprecated
and removed from HTML5 already. How do we support this important feature?
As far as I can tell, WebKit can't drop the support for stylization by a
font element due to the backward compatibility because WebKit is also used
in a mail client and old mail clients doesn't support CSS at all.
Well, you can't do hiliteColor (for instance) without CSS. I assume
you mean that for any *particular* command, we should either always
use tags or always use CSS. So if the user hits bold, it should
either make b elements or add font-weight: bold, not some mix of the
two. This would be more consistent in some sense, and I can see what
you're saying.
But browsers are already consistent with respect to styleWithCSS. Why do we
want to drop this well-supported feature and add completely new third-mode
that uses both elements and CSS to style text?
But currently I'm inclined to say that it would be best to use tags
wherever possible, just because it's usually simpler and shorter.
This would match non-Gecko browsers' defaults, except I'd avoid
invalid tags like font (which aren't
Re: [whatwg] Proposal for separating script downloads and execution
So, I'm just curious, what do the participants of this thread (and Ian, specifically) feel is the most productive next step? We have 3 or 4 proposals that have all garnered various support. We've had at least one browser-developer informing us on concerns with various aspects of each. As with all other feedback on the spec, at some point I will take all the e-mail on the topic, read it, throw away any e-mail repeating previously-made points or just stating support without reasoning, and then reply, making any appropriate changes to the specification. OK, then in fairness to posterity (including our future-selves), I would highly suggest/request that the the 3rd (and 4th) proposals recently discussed on this list should get their own entries on this wiki page: http://wiki.whatwg.org/wiki/Script_Execution_Control While Ian may spend the time to wade through this whole complicated thread at some point, I think the benefit of the greater community deserves a clearer and more succinct summary of where we've come thus far. --Kyle HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for separating script downloads and execution
It seems like IE9 only fires onreadystatechange on scripts which aren't in the document when in quirks mode. If the HTML5 doctype is present, it'll still load scripts before inserting them into the document, but onreadystatechange doesn't seem to be fired. Can someone confirm? -- Glenn Maynard
Re: [whatwg] Improvement of the Application Cache
Sounds related to Programmable HTTP Caching and Serving (formerly titled DataCache API): http://dev.w3.org/2006/webapi/DataCache/ [[[ This document defines APIs for off-line serving of requests to HTTP resources using static and dynamic responses. It extends the function of application caches defined in HTML5. ]]] - Joe On Mar 3, 2011, at 1:50 PM, Michael Nordman wrote: Sounds like there are at least two feature requests here... 1) Some way of not adding the 'master' entry to the cache. This is a common feature request, there's another thread about it specificially titled Application Cache for on-line sites. 2) The ability to add(), remove(), and enumerate() individual urls in the appcache. Long ago, there were interfaces on the appcache drawing board to allow that. They got removed for a variety of reasons including to start simpler. A couple of years later, it may make sense to revisit these kind of features, although there is another repository also capable of storing ad-hoc collection of resources now (FileSystem), so i'm not sure this feature really needs to be in the appcache. @Hixie... any idea when the appcache feature set will be up for a growth spurt? I think there's an appetite for another round of features in the offline app developers that i communicate with. There's been some recent interest here in pursuing a means of programatically producing a response instead of just returning static content. On Wed, Mar 2, 2011 at 7:40 AM, Edward Gerhold edward.gerh...@googlemail.com wrote: Hello, i would like to suggest an improvement for the Offline Web applications. Problem: I´ve found out, that i can not Cache my Joomla! Content Management System. Of course i´ve read and heard about, that the application cache is for static pages. But with a little change to the spec and the implementations, it would be possible to cache more than static pages. I would like to cache my Joomla! system. To put the scripts, css and images into the cache. I would like to add the appcache manifest to the index.php file of the Joomla Template. What happens is, that the index.php is cached once and not updated again. I can not view new articles. The problem is, that i can neither update the Master File, nor whitelist it. And this is, what my request or suggestion is about. I would like to whitelist the Master file, where the appcache manifest is installed in. Or i would like to update this file, or any file else, i would like to update, on demand. If there is any possibility, to do that already, please tell me. But i think that is not the case. Caching the CMS by making it possible to update or to whitelist certain files, the always dynamic frontpage or /index.php, would be the hammer to nail the board on the storage. Rules: The things, which should be considered are: *To allow to fetch the Master file, e.g. index.php* *in Joomla! over the NETWORK,* while any other file in the manifest get´s fetched or cached like before. Which is the most important for me, to get Joomla! into the cache. Javascript: For the script i would like to add *applicationCache.updateMaster()*, which forces the browser to fetch the file again. I think, this is impossible today, to update exactly this file. For the function, i could add a button to my page, to let the user choose to update the file. The second function would be *applicationCache.updateFile(url)*, which could be triggered by a button and script, too. I could let the user update certain articles. With that i would like to suggest* applicationCache.addToCache(url)* to add files manually or programmatic, which can not be determined by the manifest. Urls like new articles (*), i would like to read offline. I would like to add them to the cache, if the link appears, maybe on the frontpage. I would have to add the manifest to the CMS anyways, so i could add a few more functions to the page, of course. * applicationCache.removeFromCache(url)* should be obvious and helpful with the other functions. Good would be, to be able to iterate through the list of cached objects and even the manifest, with the update, add, remove functions, it would be very useful to work with the filenames and parameters. [(*) I could let the user decide wether he wants to download my mp3 files to the appcache or not, and fulfill the wish with the javascript functions. Maybe he´s got no bytes left or wants only the lyrics.] Conclusion: The application cache is very powerful. But it is very disappointing, that it is only useful for static pages. With a little improvement to the Offline Web applications chapter, and of course to the browsers, it would be possible to cache any Content Manager or dynamic page. And that would let the appcache become one of the most powerful things in the world. I could read my Joomla! offline, could update the cached files, if i want
