Re: [whatwg] Cross-domain databases; was: "File package protocol and manifest support?"

[Ian Hickson]

On Wed, 9 Mar 2011, Brett Zamir wrote:
>
> With IndexedDB apparently gaining traction, I'd like to reiterate my 
> proposal for cross-domain shared databases. Though I'll admit I'm not 
> sure I understand all of the concerns raised earlier, I do want to offer 
> my own rebuttals to these counter-points as I understand them (and 
> subsequently highlight some additional advantages):
> 
> While cross-domain shared workers might be more ideal for sites which 
> wanted more granular control of how their shared data was accessed, and 
> no doubt a positive idea for sites wishing to go to the trouble to set 
> it up, my strong feeling is that making one's data shared should also be 
> possible in an easy a manner as setting up the database itself. 
> Requiring the developer to create their own API for others to access 
> their database would no doubt A) prevent some sites which might be open 
> to sharing their data from doing so, and B) Add barriers for those 
> wishing to mash-up different sites' data, as it would require study of 
> not only the site's unique data store, but also its means of allowing 
> access to it.

While I think there is validity to what you say here, the biggest question 
in my mind is whether there is really a demand for this yet.

Given that it is possible to share a database with s, shared 
workers, and postMessage(), I think we should first see how many people 
actually do that. If it turns out to be a common thing to do, then it 
makes sense to specifying something.

See also this entry in the FAQ:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] script element onerror event

[Ian Hickson]

On Sat, 28 May 2011, John J. Barton wrote:
>
> To allow optional JavaScript download, some widely used JavaScript 
> libraries, such as jQuery and requireJS, use script elements added to 
> the document dynamically by JavaScript. (Of course this feature is also 
> used by applications directly as well).  For normal deployment this 
> approach works well in practice. At development time however, or in the 
> presence of network or server problems, the approach gives poor error 
> recovery information. Fundamentally the problem is that the insertion 
> mechanism has no error return path.
> 
> The script element does support one event, 'onload' which fires after 
> the script has finished loading. I suggest the addition of one new 
> event, 'onerror', which fires in every other case. For examples, a 
> network error (4XX, 5XX) or JavaScript parse error would trigger onerror 
> but not onload.  On the other hand, a runtime error for the 
> outer-function of the script element would trigger onload (I guess), but 
> the developer can handle this with try/catch.
> 
> Very long load times would still have poor error recovery information, 
> but developers could implement UI to signal "loading..." once they know 
> they will get some update event eventually.

On Sun, 29 May 2011, Mike Wilson wrote:
> 
> This event is actually already speced, see #14 "fire a simple event 
> named error at the element" in: 
> http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script (and 
> the onerror attribute is valid for all elements)

On Sun, 29 May 2011, John J. Barton wrote:
> 
> Step 14 is unclear or incomplete however:
> " If the|src
> |attribute's
> value is the empty string or if it could not be resolved,..."
> 
> Does this mean the error handler will be called in the case of 4XX, 5XX, 
> and syntax errors?

It's not incomplete, it's just that you don't know you got a 4xx/5xx at 
that step, you only know after you've hit the network. The 'error' event 
is fired lower down for that case.


On Sun, 29 May 2011, John J. Barton wrote:
> 
> (I've not seen a "for" attribute on a script element. Is there any 
> documentation on what it does?)

It doesn't do anything useful per spec. It's an old IEism.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Run javascript code once

[Ian Hickson]

On Thu, 31 Mar 2011, Diogo Resende wrote:
> 
> I would like your opinion on this use case:
> 
> I have an app divided in several modules, each one has a javascript code 
> that needs to run to show the module page and init the interactions. The 
> app is not supposed to reload to show each module.
> 
> What is the best way to fetch the javascript code and run it? Add a 
> 

[whatwg] Appcache feature request: abort cache update

[Alexey Proskuryakov]

Appcache API has everything to provide progress UI to the user, but with every 
good progress bar, there goes a Cancel button.

I suggest adding an abort() method to ApplicationCache interface.

- WBR, Alexey Proskuryakov

Re: [whatwg] Whitelist for registerProtocolHandler()

[Aryeh Gregor]

On Thu, Jun 9, 2011 at 3:35 PM, rektide  wrote:
> 1. The current use case for registerProtocolHandler is intra-page.  For one 
> example, here's
> the MDC docs:
> "Note: Web sites may only register protocol handlers for themselves. For 
> security reasons,
> it's not possible for an extension or web site to register protocol handlers 
> targeting other
> sites."

That only means that the protocol can only be *handled* by the current
origin.  It still intercepts links *from* any page, or even that the
user manually types in the location bar.  So the security issues
remain.

> 2. Someone who wishes to register a 'web' protocol for their own usage ought 
> be forced to
> consider that this protocol may not necessarily remain in their own purview.

And?

> 3. It forces syntactical cruft upon people wishing to exercise this 
> capability, and that
> cruft makes website handled protocols less likely to be used, to look cheap, 
> and to be
> regarded as second class citizen of the protocol world.  Tim Bray has already 
> lamented
> enforcing the // upon the world, and if web+ protocols take off this will 
> exacerbate his two
> character mistake by another four oh-so-valuable characters.  We ought not 
> double the
> obvious + preventable mistakes of the past.

Yes, it stinks.  But anything else is a potential security
vulnerability.  We don't know what protocols people are using out
there, and we don't want to allow web pages to intercept any protocol
someone might be using.  Note that if a protocol proves popular, it
can always be added to the whitelist in unprefixed form, and people
can move to the unprefixed version as browser support for the updated
whitelist is deployed.  There's no reason anything has to be
permanently prefixed if it catches on.

> 4. Whitelisting seems fundamentally 'anti-web' by enforcing only what is out 
> there already.

Whitelisting is ubiquitous in security, including on the web.
Blacklisting is just not safe.

> I strongly support the notion that web pages ought be able to provide their 
> own content &
> protocol handlers — especially in an OS native fashion — and it strikes me as 
> unweildy to
> place this ^web\+[:soo:]+  restriction on this extension point.  Personally, 
> I think it is
> very high priority to reconsider Ian's informal decree (which has since been 
> pressed into
> service in WebKit[2]), and formalize concensus around this issue.

In that thread, implementers of Chrome and Opera agreed with Ian, and
no implementers disagreed.  It's not a decree by Ian, it's up to
implementers to decide what they want to do.

[whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with "nonzero" (default) and "evenodd" options

[Chris Jones]

In 2D canvas, determining whether a point is "inside" a path is currently 
always done using the non-zero winding rule.  I propose extending 2D canvas to 
allow determining inside-ness using the even-odd rule.  The motivation is

 (1) Many/most 2D graphics libraries have this feature; canvas should have it 
for completeness.  Some other languages/libraries that support even-odd fill 
(in alphabetical order): cairo, Direct2D, GDI, PDF, PostScript, Quartz, skia, 
and SVG.

 (2) While the nonzero-winding and even-odd rules are equivalent in the sense 
that there's nothing that can be drawn with one that can't be drawn with the 
other, some figures are simpler to draw with one rule instead of the other.  We 
should add even-odd fill for author convenience.

 (3) Using one rule over the other may result in better performance, by 
decomposing to less geometry.

The concrete proposal is

  interface CanvasRenderingContext2D {
//...
attribute fillRule;  // "nonzero", "evenodd" (default "nonzero")
//...
  };

The names "nonzero" and "evenodd" were chosen to match the SVG specification 
[1].  The SVG specification can be used as a reference for the semantics of 
even-odd fill.

|fillRule| applies to all operations currently "hard-coded" to use the 
nonzero-winding rule to determine inside-ness.  The change proposed here is, 
when computing inside-ness, use the rule currently specified by |fillRule|.

The default value of |fillRule| is "nonzero", for backwards compatibility.  The 
|fillRule| attribute is part of the canvas state saved by save() and restored 
by restore().  Script attempting to set |fillRule| to a string not one of 
"nonzero" or "evenodd", say "garbage", would have no effect (i.e. *not* change 
the value of |fillRule|).

Mozilla has implemented this proposed spec as |mozFillRule| [2].  It will be 
available in Firefox "Nightly" builds starting June 11th.

Cheers,
Chris

[1] http://www.w3.org/TR/SVG/painting.html#FillProperties
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=655926

Re: [whatwg] Support for page transitions

[Aryeh Gregor]

On Thu, Jun 9, 2011 at 7:41 AM, Mikko Rantalainen
 wrote:
> I'm fine with in-page transitions using CSS but I don't think that
> current page should be able to apply all available in-page transitions
> for transitioning to another page. (In addition, it could be a bit hard
> to describe how current and next document should transition when
> currently available transitions deal with one element at a time.)

You could just have the transition apply to the root element.

> Currently loaded page should not cause transitioning to a new page to
> take as long as the current page wishes. For example, user could type
> new address into location bar or load a bookmark. Of course, the UA
> could totally skip transitions in such special cases. I see in-page
> transitions less dangerous than inter-page transitions because such
> transitions affect exactly one URL; the inter-page transition should
> exists to provide additional user hint about the document change and as
> such, that should be more balanced between author control and UA
> control. Currently in-page transitions are totally author controlled.

Certainly pages should only be allowed to control transitions when the
navigation is due to a link in the page or something else intrinsic to
the page, not when the user types in the URL bar.  I don't have a
strong opinion on whether such transitions should be restricted
further -- certainly browsers might want to cap the length, or allow
users to disable them, or similar.

> For example, if I have a wizard that logically forks to two different
> paths, then rel="next" should not be used. Or at least
> http://microformats.org/wiki/existing-rel-values describes "next" as
> following:
>
> "Refers to the next document in a linear sequence of documents. User
> agents may choose to preload the "next" document, to reduce the
> perceived load time."
>
> Notice the word "linear". I think rel="maybe-next" would describe what
> I'm thinking. Or perhaps rel="next" should be changed to mean "maybe next".

It's pretty vague, so I think you could use it anyway.  There's no
hard requirement there.

> Also note that rel="next" is not currently allowed for submit buttons at
> all. So either rel="next" must be relaxed here, too, or we need a new
> attribute. I'm fine with either choice.

Well, we could allow rel here in principle.  But more problematically,
there's no way to specify a relation *or* CSS when navigating the page
programmatically, like via document.location.  I don't have a good
answer here.

Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?

[Aryeh Gregor]

On Thu, Jun 9, 2011 at 3:49 AM, Ian Hickson  wrote:
> On Tue, 1 Mar 2011, Aryeh Gregor wrote:
>> We could define script APIs, or features of them, as deprecated if
>> browsers were willing to log some kind of notice to their error consoles
>> when the feature is used.  They all have error consoles with different
>> reporting levels already, so it shouldn't be a pain for them to
>> implement.  They can have the deprecation warnings off by default so
>> they don't clutter the output.  At least Firefox already does this for
>> some things, like document.getSelection() (although that message will
>> probably go away in a future release).
>>
>> Of course, this would only be useful if we had a good alternative to
>> recommend.  "Don't use alert(), use some giant JavaScript library
>> instead" is unlikely to be a very helpful message.  But it would be nice
>> for some of the crazier or more horrible APIs, if they have saner
>> replacements.
>
> Do we have any data on whether these warnings have any useful effect?

I don't, but then, browsers barely ever emit such warnings.  So it
would be worth trying to mark some methods as deprecated in this
fashion and see if it's useful, if browsers are interested in going
along with it.  I'd predict that it would help out some percentage of
savvier authors.  Currently some authors try to avoid writing code
that validators tell them is bad, so it's a good guess that some would
try to avoid writing code that browsers tell them is bad.

Of course, we'd have to be careful to only do this when we're
reasonably sure that authors really want to never use the feature even
in legacy code, not for every property or method that we wish didn't
exist.  I'm not sure if there really are very many such properties or
methods.

Re: [whatwg] Session Management

[Cameron Heavon-Jones]

On 10/06/2011, at 4:23 PM, Dave Kok wrote:
>>> Ultimately a user-agent must use whatever
>>> method required by the server not the method defined by the author. A
>>> user- agent can transparently find out which method to use with a HEAD
>>> request. Or if transport layer security is used simply guess one and see
>>> if it works and try again if it doesn't.
>> 
>> I'm not sure i agree. The server has served up the page so ultimately it is
>> in control. If the author specifies something which the server can not
>> handle, that's just an authoring bug is it not?
>> 
>> I also don't think an agent should be making any guesses...this would
>> definitely seem to violate the authority to define the modus operandi.
> This is assuming the form's action targets the same domain. I see no reason 
> why it should. On top of that authentication is a protocol thing so it's best 
> to leave most of the details at that level and not expose those to a higher 
> level. As rational you can look at the XMLHttpRequest.open function. It only 
> allows an author to supply a username and password and not what method to use 
> or any additional parameters.
> 

But, it also allows for manually setting the Authorization header which takes 
precedence over the method arguments.

What do you mean by "it's a protocol thing"? The idea is to provide a UI to 
enable a human to interact with the protocol, this must be present in some way, 
either by the UA as at present, or through forms as suggested.

>> 
>>> Also binding the username and password input fields to the authorization
>>> header should properly not be done by reserving names in the name
>>> attribute of the input field. I would suggest using a special purpose
>>> attribute like authorization to declare their binding. Otherwise authors
>>> have to cope with reserved names which is properly unacceptable
>>> backwards-compatible wise.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Dave Kok
>> 
>> But, in reference to backwards compatibility, the authorization must be
>> explicitly declared so this wouldn't be applied universally.
> Yes but browsers not supporting the new feature would simply post the 
> username 
> and password without using any authentication method. However those fields 
> are 
> suppressed if no the name attribute isn't used. Thus using a new attribute 
> has 
> my preference. Also to allow building a work around for non-conforming 
> browser 
> which will exists for many years to come even is this feature finds it way 
> into 
> the spec.

But, the authorization would only be applied when instructed through the 
application of the specific header. This means that there can't be any conflict 
with existing pages\forms as form headers don't currently exist.

There is a benefit to binding the parameters from input names - for old 
browsers which don't support the new headers they will at least send a request 
to the server which can be setup to handle legacy requests as form encoding, 
probably falling back to setting up a cookie session. As you noted, if new 
attributes are introduced, no data will be sent.

The benefit i see in allowing binding from input name is that any of the input 
types can be used to collect the necessary data to form the request. For 
realms, this could be a multi-select.

sorry, i didn't mean to pollute the thread...it seemed related to the issue but 
is probably going on a tangent.

thanks,
cameron jones

Re: [whatwg] Form controls inside a label but not labelled by it

[Mounir Lamouri]

On 06/04/2011 12:57 AM, Ian Hickson wrote:

On Thu, 17 Feb 2011, Mounir Lamouri wrote:

According to a comment of Hixie in [1], this case has been handled by
the specs in 2004 but it doesn't seem to be any more and UA's have a
very different behaviour here:
- Firefox: focus and activate the labelled element ;
- Webkit: focus the form control and activate the labelled element ;
- Presto and IE9 RC: focus the form control (doesn't activate the
labelled element).

I think Webkit's behaviour makes the more sense here and it would be
nice to have it specified.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=213519
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=595270


Oops, not sure why the text was lost in the WF2 merge.

I've added equivalent text back. It describes the Opera/IE behaviour;
could you elaborate on why the WebKit behaviour is better?


Webkit behavior makes more sense because it tries to combine expected 
behavior for clicking inside a label and for clicking on an interactive 
element. It sounds much more natural.
Opera/IE behavior is similar to ignoring the fact that the interactive 
element is inside a label. Basically, Opera and IE are assuming that the 
author didn't want to write what he/she wrote. I do not think that is a 
sane behavior when they are good and real use cases for it.



Authors can emulate the WebKit behaviour if they really want it by just
calling .click() on the element they want to have activated when the
target is focused.


Sure. Like the the Firefox one ;)

--
Mounir

Re: [whatwg] Session Management

[Cameron Heavon-Jones]

On 10/06/2011, at 4:23 PM, Dave Kok wrote:

> Op vrijdag 10 juni 2011 16:07:01 schreef u:
>> On 10/06/2011, at 2:12 PM, Dave Kok wrote:
>>> I very much like the header type as a generic feature but would suggest
>>> not using it for HTTP authorization. As for user-agents to support it
>>> through forms have to use special processing anyways. So I would suggest
>>> simply declaring it on the form element itself as an attribute. When
>>> using XMLHttpRequest one already has the ability to supply credentials
>>> with the open function. So when using a input elements without a form
>>> element there is no need for an authorization feature. Also I would
>>> suggest that the attribute does not have a value or that it is at least
>>> optional and when supplied is only a hint to the user-agent.
>> 
>> I most definitely concur the usefulness of header fields :)
>> 
>> The problem with authentication is it's pre-existing complexity and getting
>> existing technologies to converge in a unified way.
>> 
>> The attraction to this is that with the base extensions to forms it seems
>> like the ability to declare authentication is only a short step away, and
>> it's complexity provides a thorough use case for identifying the necessary
>> specification edge cases.
> My my most important comment.  Is not to use the name attribute of the input 
> field for specifying a binding to an extension. You don't want to constrain 
> the 
> usage of existing attributes for new extensions. Use new attribute to specify 
> the binding.
> 

hmmmi see your point

>> 
>>> Ultimately a user-agent must use whatever
>>> method required by the server not the method defined by the author. A
>>> user- agent can transparently find out which method to use with a HEAD
>>> request. Or if transport layer security is used simply guess one and see
>>> if it works and try again if it doesn't.
>> 
>> I'm not sure i agree. The server has served up the page so ultimately it is
>> in control. If the author specifies something which the server can not
>> handle, that's just an authoring bug is it not?
>> 
>> I also don't think an agent should be making any guesses...this would
>> definitely seem to violate the authority to define the modus operandi.
> This is assuming the form's action targets the same domain. I see no reason 
> why it should. On top of that authentication is a protocol thing so it's best 
> to leave most of the details at that level and not expose those to a higher 
> level. As rational you can look at the XMLHttpRequest.open function. It only 
> allows an author to supply a username and password and not what method to use 
> or any additional parameters.
> 

I agree, there is no reason the action should be the same domain.

>> 
>>> Also binding the username and password input fields to the authorization
>>> header should properly not be done by reserving names in the name
>>> attribute of the input field. I would suggest using a special purpose
>>> attribute like authorization to declare their binding. Otherwise authors
>>> have to cope with reserved names which is properly unacceptable
>>> backwards-compatible wise.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Dave Kok
>> 
>> But, in reference to backwards compatibility, the authorization must be
>> explicitly declared so this wouldn't be applied universally.
> Yes but browsers not supporting the new feature would simply post the 
> username 
> and password without using any authentication method. However those fields 
> are 
> suppressed if no the name attribute isn't used. Thus using a new attribute 
> has 
> my preference. Also to allow building a work around for non-conforming 
> browser 
> which will exists for many years to come even is this feature finds it way 
> into 
> the spec.
> 

understood

>> 
>> I'm more thinking of a way to initiate the http authentication in html
>> instead of as a browser popup. This allows for the author to define the
>> user experience in the same way they do for cookie-based authentication
>> which people have come to expect and trust.
>> 
>> I was thinking the authentication would not be applied to all forms, but
>> just as a replacement for the login form. After successful login the UA
>> would continue to apply the Authorization headers to each subsequent
>> request, until shutdown or logout.
> 
> I would expect no less. Otherwise this exercise is rather useless.
> 
> --
> Dave Kok


thanks for the feedback, will need to mull over this some more :)

thanks!

cameron jones

Re: [whatwg] Session Management

[Dave Kok]

Op vrijdag 10 juni 2011 16:07:01 schreef u:
> On 10/06/2011, at 2:12 PM, Dave Kok wrote:
> > I very much like the header type as a generic feature but would suggest
> > not using it for HTTP authorization. As for user-agents to support it
> > through forms have to use special processing anyways. So I would suggest
> > simply declaring it on the form element itself as an attribute. When
> > using XMLHttpRequest one already has the ability to supply credentials
> > with the open function. So when using a input elements without a form
> > element there is no need for an authorization feature. Also I would
> > suggest that the attribute does not have a value or that it is at least
> > optional and when supplied is only a hint to the user-agent.
> 
> I most definitely concur the usefulness of header fields :)
> 
> The problem with authentication is it's pre-existing complexity and getting
> existing technologies to converge in a unified way.
> 
> The attraction to this is that with the base extensions to forms it seems
> like the ability to declare authentication is only a short step away, and
> it's complexity provides a thorough use case for identifying the necessary
> specification edge cases.
My my most important comment.  Is not to use the name attribute of the input 
field for specifying a binding to an extension. You don't want to constrain the 
usage of existing attributes for new extensions. Use new attribute to specify 
the binding.

> 
> > Ultimately a user-agent must use whatever
> > method required by the server not the method defined by the author. A
> > user- agent can transparently find out which method to use with a HEAD
> > request. Or if transport layer security is used simply guess one and see
> > if it works and try again if it doesn't.
> 
> I'm not sure i agree. The server has served up the page so ultimately it is
> in control. If the author specifies something which the server can not
> handle, that's just an authoring bug is it not?
> 
> I also don't think an agent should be making any guesses...this would
> definitely seem to violate the authority to define the modus operandi.
This is assuming the form's action targets the same domain. I see no reason 
why it should. On top of that authentication is a protocol thing so it's best 
to leave most of the details at that level and not expose those to a higher 
level. As rational you can look at the XMLHttpRequest.open function. It only 
allows an author to supply a username and password and not what method to use 
or any additional parameters.

> 
> > Also binding the username and password input fields to the authorization
> > header should properly not be done by reserving names in the name
> > attribute of the input field. I would suggest using a special purpose
> > attribute like authorization to declare their binding. Otherwise authors
> > have to cope with reserved names which is properly unacceptable
> > backwards-compatible wise.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > Dave Kok
> 
> But, in reference to backwards compatibility, the authorization must be
> explicitly declared so this wouldn't be applied universally.
Yes but browsers not supporting the new feature would simply post the username 
and password without using any authentication method. However those fields are 
suppressed if no the name attribute isn't used. Thus using a new attribute has 
my preference. Also to allow building a work around for non-conforming browser 
which will exists for many years to come even is this feature finds it way into 
the spec.

> 
> I'm more thinking of a way to initiate the http authentication in html
> instead of as a browser popup. This allows for the author to define the
> user experience in the same way they do for cookie-based authentication
> which people have come to expect and trust.
> 
> I was thinking the authentication would not be applied to all forms, but
> just as a replacement for the login form. After successful login the UA
> would continue to apply the Authorization headers to each subsequent
> request, until shutdown or logout.

I would expect no less. Otherwise this exercise is rather useless.

--
Dave Kok

Re: [whatwg] Session Management

[Bjartur Thorlacius]

On 3/11/11, Dave Kok  wrote:
> This may very well be a natural consequence of having a proposal like
> this implemented. But this would assume that implementers feel that
> having a logout button embedded into documents is considered superior
> then having a UA provided logout button. Otherwise such a thing would
> never happen. Also authors have the freedom to use either a custom
> authentication method or a UA provided authentication method. Though I
> too prefer the UA provided authentication method we can't force authors
> to do so. A UA provided logout button alone thus not cover custom
Authors shouldn't be able to force users to use their homebrew (NIH,
anyone?) authentication UI instead of the familiar one my browser of
choice sports. Whatever you do, don't encourage authors to use
authentication methods that my UA doesn't understand, and will thus
not be able to provide an interface for.

Re: [whatwg] Session Management

[Cameron Heavon-Jones]

On 10/06/2011, at 2:12 PM, Dave Kok wrote:

> I very much like the header type as a generic feature but would suggest not 
> using it for HTTP authorization. As for user-agents to support it through 
> forms have to use special processing anyways. So I would suggest simply 
> declaring it on the form element itself as an attribute. When using 
> XMLHttpRequest one already has the ability to supply credentials with the 
> open 
> function. So when using a input elements without a form element there is no 
> need for an authorization feature. Also I would suggest that the attribute 
> does not have a value or that it is at least optional and when supplied is 
> only a hint to the user-agent.


I most definitely concur the usefulness of header fields :)

The problem with authentication is it's pre-existing complexity and getting 
existing technologies to converge in a unified way.

The attraction to this is that with the base extensions to forms it seems like 
the ability to declare authentication is only a short step away, and it's 
complexity provides a thorough use case for identifying the necessary 
specification edge cases.


> Ultimately a user-agent must use whatever 
> method required by the server not the method defined by the author. A user-
> agent can transparently find out which method to use with a HEAD request. Or 
> if 
> transport layer security is used simply guess one and see if it works and try 
> again if it doesn't.

I'm not sure i agree. The server has served up the page so ultimately it is in 
control. If the author specifies something which the server can not handle, 
that's just an authoring bug is it not?

I also don't think an agent should be making any guesses...this would 
definitely seem to violate the authority to define the modus operandi.

> 
> Also binding the username and password input fields to the authorization 
> header 
> should properly not be done by reserving names in the name attribute of the 
> input field. I would suggest using a special purpose attribute like 
> authorization to declare their binding. Otherwise authors have to cope with 
> reserved names which is properly unacceptable backwards-compatible wise.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Dave Kok
> 

But, in reference to backwards compatibility, the authorization must be 
explicitly declared so this wouldn't be applied universally.

I'm more thinking of a way to initiate the http authentication in html instead 
of as a browser popup. This allows for the author to define the user experience 
in the same way they do for cookie-based authentication which people have come 
to expect and trust.

I was thinking the authentication would not be applied to all forms, but just 
as a replacement for the login form. After successful login the UA would 
continue to apply the Authorization headers to each subsequent request, until 
shutdown or logout.

thanks,
cameron jones

> Op vrijdag 10 juni 2011 14:25:07 schreef u:
>> i'd like to reference a proposal i put forward in relation to expanding the
>> functionality of forms which displays how http authentication could be
>> implemented declaratively by html authors:
>> 
>> http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html
>> 
>> thanks,
>> cameron jones

Re: [whatwg] Session Management

[Dave Kok]

I very much like the header type as a generic feature but would suggest not 
using it for HTTP authorization. As for user-agents to support it through 
forms have to use special processing anyways. So I would suggest simply 
declaring it on the form element itself as an attribute. When using 
XMLHttpRequest one already has the ability to supply credentials with the open 
function. So when using a input elements without a form element there is no 
need for an authorization feature. Also I would suggest that the attribute 
does not have a value or that it is at least optional and when supplied is 
only a hint to the user-agent. Ultimately a user-agent must use whatever 
method required by the server not the method defined by the author. A user-
agent can transparently find out which method to use with a HEAD request. Or if 
transport layer security is used simply guess one and see if it works and try 
again if it doesn't.

Also binding the username and password input fields to the authorization header 
should properly not be done by reserving names in the name attribute of the 
input field. I would suggest using a special purpose attribute like 
authorization to declare their binding. Otherwise authors have to cope with 
reserved names which is properly unacceptable backwards-compatible wise.














--
Dave Kok

Op vrijdag 10 juni 2011 14:25:07 schreef u:
> i'd like to reference a proposal i put forward in relation to expanding the
> functionality of forms which displays how http authentication could be
> implemented declaratively by html authors:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html
> 
> thanks,
> cameron jones

Re: [whatwg] Session Management

[Cameron Heavon-Jones]

i'd like to reference a proposal i put forward in relation to expanding the 
functionality of forms which displays how http authentication could be 
implemented declaratively by html authors:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html

thanks,
cameron jones


On 10/06/2011, at 1:00 AM, Ian Hickson wrote:

> On Tue, 1 Mar 2011, Boris Zbarsky wrote:
>> On 3/1/11 5:29 PM, Ian Hickson 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.
>> 
>> For what it's worth, Firefox even has UI for this
> 
> Indeed.
> 
> 
> On Wed, 2 Mar 2011, Dave Kok wrote:
>> 
>> You can also login using AJAX requests. This breaks the idea of it being 
>> purely a UI matter.
> 
> How so?
> 
> 
>> Also browsers don't all do this.
> 
> They all don't do whatever else we come up with to solve this, too.
> 
> 
>> In my opinion it is not sufficient to have solely the browser UI cover 
>> this particular feature. Also looking forward to a feature like app mode 
>> shipping in Google chrome, I remember Firefox having something similar, 
>> it would be really useful if it could be controlled from within a web 
>> page.
> 
> If you really want to control it from within the page, just use another 
> credential mechanism, like form-submitted login and cookies.
> 
> 
>> Also as web developers are requesting this over and over again there 
>> seems to be a real need.
> 
> Compared to other features, this is not requested that often.
> 
> 
>> Just saying that the web browser UI should do it is not getting the job 
>> done.
> 
> Why would it be any more effective to do anything else?
> 
> 
>> Most prominently however how is a web browser suppose to know which 
>> credentials to dump when the user hits a logout button in the web 
>> browser UI. During a page load multiple origins can be accessed and all 
>> may require credentials.
> 
> That's also a UI issue. For example, the browser could just dump all the 
> credentials for the sessions started in the current tab, or it could show 
> the user a list of credentials that the user can pick to drop.
> 
> 
>> But it seems mostly natural in a web application to include a logout 
>> button. I don't know of any web applications not having one.
> 
> If they all have it, then there's no problem. :-)
> 
> 
>> So why is it suddenly sufficient that the browser UI could have a logout 
>> button?
> 
> For HTTP auth, the login is also done by the browser's UI. So it makes 
> sense that the logout should be done by the browser also.
> 
> 
>> And if it should why is it not being required in any spec?
> 
> We don't require UI of any kind.
> 
> 
>> The whole purpose of these specs is to have some common denominator so 
>> building web sites/applications does not require having to know 
>> everything about every possible browser in use. It's about making life 
>> easy not hard. I really think some influential spec should say something 
>> about this.
> 
> There aren't really any influential specs when it comes to UI (or much of 
> anything else -- specs only appear influential if they happen to spec what 
> implementors want to do anyway).
> 
> 
 I prefer to use HTTP authentication mostly as it is build-in anyways 
 and has richer features then pure form-based authentication.
>>> 
>>> What features does it have that other mechanisms do not?
>> 
>> HTTP authentication like HTTP itself is stateless. Form-based 
>> authentication isn't and requires the extra hurdle of having to persist 
>> a session key.
> 
> Ironically, it's the fact that HTTP authentication is state_ful_ that is 
> causing you trouble here.
> 
> 
>> As far as I can judge, form-based authentication has no pros over HTTP 
>> authentication. Other then the web developer being able to create a 
>> working logout procedure. Please note that one can also use a form to 
>> gather the credentials and login in through AJAX. But mostly I like the 
>> idea of it being in the HTTP protocol itself. Rather then implemented on 
>> top of it.
> 
> That seems very arbitrary.
> 
> 
>> It allows for futures expansions like upgrading to more secure 
>> authentication methods like Kerberos (I believe Microsoft is already 
>> doing this) or using client certificates (already possible). I don't see 
>> this happening with form-based authentication. When logging out is 
>> possible and well supported I actually see these more secure 
>> authentication methods becoming mainstream.
> 
> I'm rather skeptical, personally. Client certificates are an 
> authentication mechanism that baffles regular users.
> 
> 
> On Wed, 2 Mar 2011, Dave Kok wrote:
>> 
>> 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

Re: [whatwg] Recursion and loops of Microdata items

[Philip Jägenstedt]

On Thu, 09 Jun 2011 19:01:24 +0200, Ian Hickson  wrote:


On Thu, 9 Jun 2011, Philip Jägenstedt wrote:


As for the spec, I don't think it can or needs to define the algorithm  
on a
form suitable form implementation. Something along these lines would be  
much

clearer for reference:

1. create a (possibly disconnected) graph of all the items in the  
document (or

subtree)
2. find the strongly connected components
3. create a list of "loopy" items: those that are in the same component  
as any

other item

The traversal would remain mostly as before, but whenever an item is
encountered, one checks if it is in the list of "loopy" items and if so
ignores it. Since "loopy" is a global property, you'll see the same  
properties
regardless of the path taken to reach it, which may or may not be the  
case

with the current spec. (In any case, it's a nice feature.)


The main reason I didn't do something like this with the current spec was
that I was trying to minimise the work needed when implementing the API  
in

a dynamic situation. The above would imply that any time anything in the
document changed in a way that could affect microdata, you'd have to redo
the whole document before the next time the API was invoked. That seems
expensive. (Consider the WHATWG spec, which has microdata in it and is
about 5MB. Do you really want to crawl the whole document looking for
microdata each time the API is invoked?)

What I had tried to do when implementing the spec is start at whatever
point in the DOM the API call was related to, and then search for loops
from that point, and drop anything loopy. That's still expensive, but it
at least minimises the total amount of work.

Does that make sense?

If the expense isn't a big deal then I don't mind doing it the other way
too, but this seems like an API that we're going to have enough trouble
getting implemented in the first place without giving implementors a
reason to avoid doing it at all.


I don't think the spec needs to be giving suggestions for efficient  
implementation for live collections, because we inevitable won't implement  
exactly that algorithm anyway. It is a problem if the algorithm doesn't  
clearly map to some simpler higher-level behavior, as we certainly don't  
want to emulate some edge-cases just to follow the letter of the spec.


But, let's disregard the exact algorithm for a moment and only consider  
the actual requirement we're suggesting: "any item which can reach itself  
by following itemrefs should be removed"


It seems to me that it's quite possible to check this criteria while  
traversing using an algorithm of similar structure to what is already in  
the spec. One issue is that one must first find all the loopy items and  
then remove them in one step, rather than interleaving the  
checking/removing. However, it seems that this could be solved by simply  
flagging them instead of actually removing them, so that they will still  
take part in later loop-checks.


Am I missing something significant about the spec'd algorithm that would  
make it more efficient than the above?


If we just go ahead and show an efficient (enough) implementation of loop  
removal using the suggested criteria, I assume that would be convincing  
enough? Or do you really think that itemref is useless and complicated  
enough that it would be better to throw it overboard?


--
Philip Jägenstedt
Core Developer
Opera Software