date:20100802


On 8/2/10 5:20 PM, Ian Hickson wrote:

Or does "stop the currently running task" in #spin-the-event-loop imply
a jump to step 2 of the algorithm under #processing-model2?


Yes.


OK, that might be worth clarifying.


(Note: I still have a problem with the way "pause" is defined here, but
I've raised that before, I believe.)


I think we all have a problem with "pause", but I don't know what we can
do about it. I don't have any pending feedback from you on this topic, as
far as I can tell.


Odd.  I definitely sent something about it (in particular that it 
doesn't seem very easily implementable in terms of network event 
behavior, if the pause is waiting on a network event and other network 
events need to not be delivered in the meantime).


-Boris

Re: [whatwg] suggestion for HTML5 spec

On Mon, Aug 2, 2010 at 7:09 PM, Ian Hickson  wrote:
> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson  wrote:
>> > On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> >> >
>> >> > Why would a user ever want anyone to disable their GPU acceleration?
>> >>
>> >> I believe I've heard people say that they might sometimes want this for
>> >> power management, i.e. performing the same computation on the GPU might
>> >> take more power than performing it more slowly on the CPU. I imagine
>> >> this would depend on the specific configuration and computations
>> >> involved, though.
>> >
>> > This seems like a matter for the user, not the Web page, though.
>>
>> Ah, I knew you were going to say this. I agree, but I can also imagine
>> that the way the user selects this is by choosing one of two different
>> resources from a page, just like we do today for videos of different
>> bandwidths.
>
> It seems better to have a way for the user agent to automaically negotiate
> the right bandwidth usage based on user preference, too.
>
> Any setting like this that we offer authors _will_ be misused, possibly as
> often as used correctly. Unless there's a really compelling reason to have
> it, it seems better to let the user be in control.

If users can choose between two links on a page labelled "high FPS -
will destroy your battery" and "low FPS", they are in control, in a
way that is easily understood by the user and allows them to make the
choice at the point in time that it matters. Compare this with
changing the streaming settings on QT Player or Windows Media Player,
or even toggling the "use the video card" button on your laptop (and
hoping that the content is smart enough to degrade gracefully instead
of choking).

We've seen this exact same argument play out over the last fifteen
years in video on the web. The technology for detecting and adjusting
bandwidth dynamically has been around forever (actually implemented,
even), and yet for every one multi-bitrate stream available on the
web, I imagine there are very many more that are single-bitrate. A big
part of the reason for this is because doing it this way is (in my
opinion) a better user experience.

That said, I do also agree that it opens up the possibility for abuse
or incorrect usage (just like it's possible to send a HD stream down a
modem line). And, I'm not actually advocating a solution here one way
or another, just attempting to answer your question.

-- Dirk

Re: [whatwg] Expanding the cite element

On Wed, 5 May 2010, Simpson, Grant Leyton wrote:
>
> Is there any value in adding an "href" or "uri" or similar attribute to 
> the  element to indicate a location for a work (or information 
> about the work) or, in the case of a URI, an indicator that can be used 
> as a reference programmatically?

I don't know; is there? What would the use case be?


>  has a "cite" attribute, so it seems to me that if we have a place to 
> link to further information in  it makes sense to do so in .

To be honest,  hasn't been very successful. One could argue it is 
a failed experiment. :-) If it wasn't more or less harmless, I'd probably 
be arguing to remove it.


> If it were a URI (and therefore not necessarily retrievable), it would 
> help in cases where the same work gets referenced in slightly different 
> ways:
> 
> As Ashley Crandall Amos says in  uri="http://example.com/books/crandall/linguisticmeans";>Linguistic Means 
> of Determining the Dates of Old English Literary Texts ... Amos 
> also mentions in  uri="http://example.com/books/crandall/linguisticmeans";>Linguistic 
> Means

Works tend to have as many different URIs to reference them as titles, 
sometimes more. :-)


On Thu, 6 May 2010, Edward O'Connor wrote:
> 
>  has a much worse fallback story than simply embedding a link 
> in .
> 
> > As Ashley Crandall Amos says in  > uri="http://example.com/books/crandall/linguisticmeans";>Linguistic 
> > Means of Determining the Dates of Old English Literary Texts 
> > ... Amos also mentions in  > uri="http://example.com/books/crandall/linguisticmeans";>Linguistic 
> > Means
> 
> Consider how the above would work in legacy browsers, and then consider 
> how this would work in them:
> 
> As Ashley Crandall Amos says in  href="http://example.com/books/crandall/linguisticmeans";>Linguistic 
> Means of Determining the Dates of Old English Literary Texts 
> ... Amos also mentions in  href="http://example.com/books/crandall/linguisticmeans";>Linguistic 
> Means

Using  does seem like it would solve this neatly without additional 
effort.


On Thu, 6 May 2010, Schalk Neethling wrote:
>
> I guess this is the 'Paving the cowpaths' situation. Is there a 
> 'standard' where most developers do as in the sample by Ted?

That's a good question; have people found this useful enough to work 
around the lack of an attribute here? If not, maybe there's no problem to 
solve in the first place.


On Fri, 7 May 2010, Simpson, Grant Leyton wrote:
> 
> 1. Referencing something in the href attributed of an  tag implies 
> that the URI will resolve to a URL, that is, that it will be accessible 
> on the web at that address. Not every URI is a URL, though. That's what 
> I was trying to do with a "uri" attribute for the  tag is to 
> identify the resource, not necessarily link to it.

Any link could be resolved; for example the browser could have a handler 
for isbn: links that looks up the book on Amazon or Google Books.


> 2. We would have to formally define what  within  means, 
> otherwise we would leave the pairing up for interpretation.

Until we know that this is a problem people really want solving, that's 
probably ok.


> 3. Are there instances where tags that can be used separately take on a 
> different meaning in relation to one another?  I know what  means in 
> relation to  and , but then again, I can't really use  
> outside of either of those two.

 wouldn't take on a different meaning, it would just add additional 
information to the page.


On Sat, 8 May 2010, Benjamin Hawkes-Lewis wrote:
>
> I'm not opposed to adding @cite to  but note that when you are 
> identifying a resource rather than linking to a resource, you could use 
> microdata or RDFa.
> 
> For example:
> 
>http://dev.w3.org/html5/md/#global-identifiers-for-items
> 
>
> http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description

Indeed, that may be a better solution in general.


> > 2. We would have to formally define what  within  means, 
> > otherwise we would leave the pairing up for interpretation.
> 
> You stated that you want to "indicate a location for a work (or 
> information about the work)".
> 
> A hyperlink indicates the location of an item or information about an 
> item, and "a href" creates a hyperlink.
> 
> What could be the other interpretations of Work 
> title or Work title other than 
> that the hyperlink locates the work or information about the work?

Indeed.


> > 3. Are there instances where tags that can be used separately take on 
> > a different meaning in relation to one another?  I know what  
> > means in relation to  and , but then again, I can't really use 
> >  outside of either of those two.
> 
> I think the combination of "cite" and "a" to indicate a work title and 
> the location of the work or information about the work does not involve 
> changing the meaning of either "cite" or "a". This is the markup 
> equivalent of:
> 
>http://en.wikipedia.org/wiki/Object_composit

Re: [whatwg] suggestion for HTML5 spec

On Mon, 2 Aug 2010, Dirk Pranke wrote:
> On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson  wrote:
> > On Mon, 2 Aug 2010, Dirk Pranke wrote:
> >> >
> >> > Why would a user ever want anyone to disable their GPU acceleration?
> >>
> >> I believe I've heard people say that they might sometimes want this for
> >> power management, i.e. performing the same computation on the GPU might
> >> take more power than performing it more slowly on the CPU. I imagine
> >> this would depend on the specific configuration and computations
> >> involved, though.
> >
> > This seems like a matter for the user, not the Web page, though.
> 
> Ah, I knew you were going to say this. I agree, but I can also imagine 
> that the way the user selects this is by choosing one of two different 
> resources from a page, just like we do today for videos of different 
> bandwidths.

It seems better to have a way for the user agent to automaically negotiate 
the right bandwidth usage based on user preference, too.

Any setting like this that we offer authors _will_ be misused, possibly as 
often as used correctly. Unless there's a really compelling reason to have 
it, it seems better to let the user be in control.

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

Re: [whatwg] suggestion for HTML5 spec

On Mon, Aug 2, 2010 at 6:56 PM, Ian Hickson  wrote:
> On Mon, 2 Aug 2010, Dirk Pranke wrote:
>> >
>> > Why would a user ever want anyone to disable their GPU acceleration?
>>
>> I believe I've heard people say that they might sometimes want this for
>> power management, i.e. performing the same computation on the GPU might
>> take more power than performing it more slowly on the CPU. I imagine
>> this would depend on the specific configuration and computations
>> involved, though.
>
> This seems like a matter for the user, not the Web page, though.

Ah, I knew you were going to say this. I agree, but I can also imagine
that the way the user selects this is by choosing one of two different
resources from a page, just like we do today for videos of different
bandwidths.

-- Dirk

Re: [whatwg] suggestion for HTML5 spec

On Mon, 2 Aug 2010, Dirk Pranke wrote:
> >
> > Why would a user ever want anyone to disable their GPU acceleration?
> 
> I believe I've heard people say that they might sometimes want this for 
> power management, i.e. performing the same computation on the GPU might 
> take more power than performing it more slowly on the CPU. I imagine 
> this would depend on the specific configuration and computations 
> involved, though.

This seems like a matter for the user, not the Web page, though.

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

Re: [whatwg] RFC:

On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson  wrote:
>
> This thread primarily discussed ways to allow users to log in and out of
> sites, possibly through improvements to the forms model.
>
> This is an area that seems to be under a lot of active research, so it's
> probably premature to change the HTML spec at this point. I haven't
> introduced any new form types.
>
> Some comments on a few of the specific points raised:
>
> On Tue, 4 May 2010, Eitan Adler wrote:
>>
>> Use cases:
>> 1) A screen reader that sees a form with a type=username and a
>> password field. The screen reader could just ask "Log in to this site?
>> [y/n]?". No further context would be needed.
>
> My browsers already do this on many of my sites; why can't an AT?
>
>
>> 2) UAs can more easily discover login forms and offer things such as
>> Firefox's Account Manager [1] or a "remember me" feature
>
> There are a variety of ways this can be done today (e.g. the name="",
> id="", or class="" attributes; declarative descriptions as used by [1]; a
>  pointing to a form control; microformats; etc); a new input
> field type doesn't seem necessary to do this.
>
>
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails. Furthermore some websites offer a "find other members" feature
>> where you could type in a username. I've often seen these fields filled
>> in automatically with my name.
>
> Why would sites where this doesn't work today use a new feature to do
> this? Surely they can do this now already, so why aren't they doing it?
>

I suspect that this is usually a result of ignorance. I don't think
many content authors are aware of how form-fillers work.

>
>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>
> On Tue, 4 May 2010, Steve Dennis wrote:
>> On 4/05/2010, at 9:07 AM, timeless wrote:
>> >
>> > Why would a site which doesn't cooperate with today's autofill
>> > features choose to cooperate with your proposal?
>>
>> Because id="username" isn't a standard as such.  Having it specified in
>> a spec is likely to help people adopt it more quickly.
>
> RFC3106 has specified this since 2001, and has been implemented for a long
> time: https://tools.ietf.org/html/rfc3106
>
> It didn't seem to do much to make adoption happen more quickly.
>
> Why would this new idea make things go faster?
>

I'm not sure what you mean by "has been implemented for a long time".
I am not aware of any ecommerce site of any significant size
implementing this standard. Having been responsible for one such site
from roughly 2002-2008, I had never heard of this spec, nor have
several people that I would expect to have heard of it if it had ever
achieved any traction at all. This makes me suspect that this is not a
great example to hold up.

I think it is pretty well known that simply getting a document
published and declaring it a standard is not sufficient to ensuring
adoption, but not having a document published is certainly a deterrent
to adoption.

>
>> Saying "why bother?" about all the broken sites on the web totally
>> defeats the purpose of what everyone here's trying to achieve.
>
> Sure, but we can't help these sites without their cooperation. How do we
> get them to cooperate? We've tried standards (RFC3106), we've tried making
> the user experience better (password fillers). What else can we try?
> Another  doesn't seem to address this.
>

In the absence of any recommended convention that people are actually
aware of, sites will continue to make life difficult for password
managers and form-fillers. Encouraging people to follow a convention
would be a good thing, even if we have a large legacy problem that
would have to be addressed through other things.

Suggesting that people follow 3106 instead of creating a new input
type (which is I think what you're doing) is certainly one possible
solution here.

>
> On Tue, 4 May 2010, Dirk Pranke wrote:
>>
>> I think this idea is halfway to what I'd want to see. Namely, we should
>> add an  field that triggers a powerbox/dialog (much
>> like the  dialog) that can collect whatever sort of
>> credentials are needed (username / password, two-factor auth, FB connect
>> credentials, OpenID/OAuth credentials, etc.). I agree that it should
>> probably build on top of the Account Manager spec.
>>
>> I think the whole login process needs to be taken as out of page as
>> possible. Unfortunately, the auto-login mechanism in Mozilla's prototype
>> is probably too out of page, and so there should be a way to trigger the
>> login from an in-page element (hence the above).
>
> I strongly urge people to experiment in this area. This is the kind of
> thing that should precede standardisation.
>

Agreed; I think there is a lot of value in having a conversation about
how we might improve login flows on this list, but it is too early to
think that we can standardize on one particular implementation.
Perhaps the WHATWG needs an exper

Re: [whatwg] suggestion for HTML5 spec

2010-08-02 Thread James Robinson

On Mon, Aug 2, 2010 at 6:43 PM, Dirk Pranke  wrote:

> On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson  wrote:
> > On Sat, 1 May 2010, rya...@mail.com wrote:
> >>
> >> My suggestion for the HTML5 spec is that the video tag should have a
> >> feature that can enable GPU acceleration on a user's graphics card, so
> >> it will take some stress off the CPU.
> >>
> >> Do you like my suggestion?
> >
> > Why would a user ever want anyone to disable their GPU acceleration?
> >
>
> I believe I've heard people say that they might sometimes want this
> for power management, i.e. performing the same computation on the GPU
> might take more power than performing it more slowly on the CPU. I
> imagine this would depend on the specific configuration and
> computations involved, though.
>

That's a decision for either a user or a user agent, not an author.  It
should not be toggleable from HTML.

- James



>
> -- Dirk
>

Re: [whatwg] Input URL State and Files object

On Wed, 5 May 2010, Charles Pritchard wrote:
> On 5/5/2010 12:42 PM, Ian Hickson wrote:
> > On Wed, 5 May 2010, Charles Pritchard wrote:
> > >
> > > Awhile ago, it appears, the "files" object was removed from  > > type="url">
> >
> > "files" doesn't really make much sense for type=url... Do you mean 
> > type=file?
>
> Sorry, it didn't make much sense: I meant a FileList object which 
> FileReader would use.

I still don't really see what you want here.


> > > Is there currently a method for allowing cross-domain access to an 
> > > image based on user input?
> >
> > XMLHttpRequest is the intended way to do this.
>
> XMLHttpRequest relies upon CORS headers from the server

Yes. We would have to rely on CORS whatever the solution was to be.


> Should a user intentional drag an image or URL object, or otherwise 
> select one from their browser UI, the interaction is quite similar to 
> the  object. Only, with a remote resource.

Is this a common occurance?


> I'm sorry to have approached this so poorly; what I'm looking for is a 
> solution to the following use case:
> 
> A person is assembling a digital scrap-book, using a web application, of 
> pictures they've found related to their love of kittens. Those that 
> they've downloaded to their computer, they simply drag and drop into the 
> application -- (File API, FileReader, ondrop). Those that they find on 
> the internet, they drag their bookmark onto the application, drag the 
> image onto the application, or simply, copy and paste the URL into an 
>  box.

Oh, you mean the ability for the user to give the page access to remote 
resources that themselves aren't opting in to giving the page access.

Why wouldn't  be usable for this? You should be able to 
drag any file to that, just like you can type in a URL in Windows in an 
open file dialog box.

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

Re: [whatwg] suggestion for HTML5 spec

On Mon, Aug 2, 2010 at 5:53 PM, Ian Hickson  wrote:
> On Sat, 1 May 2010, rya...@mail.com wrote:
>>
>> My suggestion for the HTML5 spec is that the video tag should have a
>> feature that can enable GPU acceleration on a user's graphics card, so
>> it will take some stress off the CPU.
>>
>> Do you like my suggestion?
>
> Why would a user ever want anyone to disable their GPU acceleration?
>

I believe I've heard people say that they might sometimes want this
for power management, i.e. performing the same computation on the GPU
might take more power than performing it more slowly on the CPU. I
imagine this would depend on the specific configuration and
computations involved, though.

-- Dirk

Re: [whatwg] Questions about meter element

On Wed, 5 May 2010, yael.aha...@nokia.com wrote:
>
> I have a couple of questions regarding the meter element.
> 
> 1. I could not find the meter element in the tables in 
> http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria.
>  
> What is the ARIA role for the meter element?

I don't think ARIA currently has one that is appropriate.


> 2. From UA requirements for showing the gauge: When representing a meter 
> element to the user, the UA should indicate the relative position of the 
> actual value to the minimum and maximum values, and the relationship 
> between the actual value and the three regions of the gauge. Considering 
> that the default size of this element is 5em width and 1em height, how 
> should the 3 regions be represented by the UA?

The simplest way is probably a flat bar with the regions coloured (e.g. 
green for the optimal region, red for the regions on the other end, yellow 
for the remaining region if any) and with a black notch showing where the 
value lies.

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

Re: [whatwg] RFC:

This thread primarily discussed ways to allow users to log in and out of 
sites, possibly through improvements to the forms model.

This is an area that seems to be under a lot of active research, so it's 
probably premature to change the HTML spec at this point. I haven't 
introduced any new form types.

Some comments on a few of the specific points raised:

On Tue, 4 May 2010, Eitan Adler wrote:
>
> Use cases:
> 1) A screen reader that sees a form with a type=username and a
> password field. The screen reader could just ask "Log in to this site?
> [y/n]?". No further context would be needed.

My browsers already do this on many of my sites; why can't an AT?

> 2) UAs can more easily discover login forms and offer things such as
> Firefox's Account Manager [1] or a "remember me" feature

There are a variety of ways this can be done today (e.g. the name="", 
id="", or class="" attributes; declarative descriptions as used by [1]; a 
 pointing to a form control; microformats; etc); a new input 
field type doesn't seem necessary to do this.

> 3) Currently autofill for usernames looks for something like 
> id="username" or name="username". However on certain websites this 
> fails. Furthermore some websites offer a "find other members" feature 
> where you could type in a username. I've often seen these fields filled 
> in automatically with my name.

Why would sites where this doesn't work today use a new feature to do 
this? Surely they can do this now already, so why aren't they doing it?

> [1] http://www.mozilla.com/en-US/firefox/accountmanager/

On Tue, 4 May 2010, Steve Dennis wrote:
> On 4/05/2010, at 9:07 AM, timeless wrote:
> > 
> > Why would a site which doesn't cooperate with today's autofill 
> > features choose to cooperate with your proposal?
> 
> Because id="username" isn't a standard as such.  Having it specified in 
> a spec is likely to help people adopt it more quickly.

RFC3106 has specified this since 2001, and has been implemented for a long 
time: https://tools.ietf.org/html/rfc3106

It didn't seem to do much to make adoption happen more quickly.

Why would this new idea make things go faster?

> Saying "why bother?" about all the broken sites on the web totally 
> defeats the purpose of what everyone here's trying to achieve.

Sure, but we can't help these sites without their cooperation. How do we 
get them to cooperate? We've tried standards (RFC3106), we've tried making 
the user experience better (password fillers). What else can we try? 
Another  doesn't seem to address this.

On Tue, 4 May 2010, Dirk Pranke wrote:
>
> I think this idea is halfway to what I'd want to see. Namely, we should 
> add an  field that triggers a powerbox/dialog (much 
> like the  dialog) that can collect whatever sort of 
> credentials are needed (username / password, two-factor auth, FB connect 
> credentials, OpenID/OAuth credentials, etc.). I agree that it should 
> probably build on top of the Account Manager spec.
> 
> I think the whole login process needs to be taken as out of page as 
> possible. Unfortunately, the auto-login mechanism in Mozilla's prototype 
> is probably too out of page, and so there should be a way to trigger the 
> login from an in-page element (hence the above).

I strongly urge people to experiment in this area. This is the kind of 
thing that should precede standardisation.

On Thu, 6 May 2010, Markus Ernst wrote:
> 
> Maybe it is a problem to have several functionalities mixed up in the 
> type attribute, such as control display, autofill and validation 
> functionalities. OTOH there are validation hints both in the type and 
> pattern attributes.
> 
> Maybe keywords could be added as possible values of the pattern 
> attribute, in order to provide standard validation types such as e-mail, 
> numeric, or maybe also date and datetime.
> 
> 
> 

This only seems to be a problem if we overload type="" for two different 
axes (the type of data, in this case an e-mail address, and the intent of 
the data, in this case a username).

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

Re: [whatwg] suggestion for HTML5 spec

On Sat, 1 May 2010, rya...@mail.com wrote:
> 
> My suggestion for the HTML5 spec is that the video tag should have a 
> feature that can enable GPU acceleration on a user's graphics card, so 
> it will take some stress off the CPU.
> 
> Do you like my suggestion?

Why would a user ever want anyone to disable their GPU acceleration?


On Sun, 2 May 2010, Simon Fraser wrote:
> 
> The only reason I can think of why this should be exposed to web authors 
> is if a browser is unable to use GPU accelerated for video without side 
> effects (like always rendering on top of the rest of the content). Such 
> an option would be similar to the "wmode" param on plugins, which is a 
> huge mess, and should be avoided at all costs. One of the benefits of 
> video being a real HTML element is that it respects CSS properties like 
> any other element.

Indeed, it seems like we'd just want this to be automatic.

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

Re: [whatwg] definition of :link and :visited should allow flexibility

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-link
> says:
>   # All a elements that have an href attribute, all area elements
>   # that have an href attribute, and all link elements that have an
>   # href attribute, must match one of :link and :visited.
> 
> A number of user agents have recently implemented changes to
> handling of :link and :visited that can't be described strictly in
> terms of an element matching a selector.  These are described in
> more detail in http://dbaron.org/mozilla/visited-privacy .
> 
> css3-selectors has an exception that allows this:
>   # UAs may therefore treat all links as unvisited links, or
>   # implement other measures to preserve the user's privacy while
>   # rendering visited and unvisited links differently. 
> 
> --http://www.w3.org/TR/css3-selectors/#the-link-pseudo-classes-link-and-visited
> 
> HTML5 should have a similar exception that allows user agents to be more 
> flexible than requiring that all of the elements listed match exactly 
> one of :link and :visited.

I've added a paragraph saying that another spec might introduce additional 
requirements here.

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

Re: [whatwg] Proposal for Web Storage expiration

2010-08-02 Thread Jonas Sicking

On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas  wrote:
> Yes, for IndexDB I think having a per-storage area expiration date completely 
> makes sense. Do you expect that IndexedDB will become a successor to 
> sessionStorage/localStorage? My belief is that the simple key-value store 
> paradigm would still end up being the default client-side data storage 
> utility, and would therefore benefit from having a per-key expiration time to 
> mimic cookie usage.

I suspect it will be much easier to add to IndexedDB than to
localStorage/sessionStorage. I don't expect the latter to go away,
though generally it seems like people are disliking localStorage
enough that it's hard to get any changes made to it.

/ Jonas

Re: [whatwg] Should :default apply to checkboxes, radios, and options?

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> For a long time, Gecko has implemented the behavior that the
> :default pseudo-class matches checkboxes, radios, and options that
> are selected by default (i.e., anything that matches :checked by
> default).  I think supporting it for option elements is explicitly
> stated in the spec where :default was introduced:
>   # One example is the default submit button among a set of buttons.
>   # Another example is the default option from a popup menu.
>   # Multiple elements in a select-many group could have multiple
>   # :default elements, like a selection of pizza toppings for
>   # example. 
> -- http://www.w3.org/TR/css3-ui/#pseudo-default
> and I think supporting it for radios and checkboxes logically
> follows from that.
> 
> However, the HTML5 spec says that :default should not apply in these
> cases:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-default
> 
> I don't feel particularly strongly about this one, but it seems like the 
> original intent of :default was to match both things that are the 
> "default button" and things that are "selected by default".
> 
> Was this difference with existing implementation behavior intentional?

No, that particular definition just didn't come to mind.


On Fri, 30 Apr 2010, Jonas Sicking wrote:
> 
> Out of curiosity, what is the use case for :default?

On Fri, 30 Apr 2010, L. David Baron wrote:
> 
> For buttons, it's common to present the button that's the default action 
> for a dialog (the one that submits if you hit enter in a textfield, for 
> example), with a thicker border.  (For example, in dialog boxes in 
> Windows.)
> 
> For radios/checkboxes, one might want to present the labels 
> corresponding to the current state in a different font (perhaps bold?) 
> or color so that if a user switches away from the defaults they can 
> switch back without having to remember what they changed. (I believe 
> I've seen UI that does this, although I can't think where.)

Since nobody seemed to object to this, and we already have an 
implementation, I've added it to the spec. I don't feel strongly about 
this either.

Note that the definition of :default isn't quite the same as what is 
:checked by default. For example, the first  here matches 
:default, even though the second is the one that matches :checked by 
default, and indeed the first can never match :checked while disabled:

   
 A
 B
   

I did this for compat with Firefox. We could change it but it would make 
the rules somewhat more convoluted.

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

Re: [whatwg] :checked should match selected option elements

On Fri, 30 Apr 2010, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#selector-checked
> defines what elements match the :checked pseudo-class.  However, I
> think it's missing an important case: selected option elements
> within a select.
> 
> http://www.w3.org/TR/css3-selectors/#checked says:
>   # For example, the :checked pseudo-class initially applies to such
>   # elements that have the HTML4 selected and checked attributes as
>   # described in Section 17.2.1 of HTML4, but of course the user can
>   # toggle "off" such elements in which case the :checked
>   # pseudo-class would no longer apply. 
> which clearly shows that it's the intent of css3-selectors that the
> pseudo-class apply in this case.
> 
> From looking at VCS history, Gecko has implemented :checked on option 
> elements since Gecko 1.8 == Firefox 1.5.

Fixed.

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

Re: [whatwg] The real issue with HTML5's sectioning model

On Fri, 30 Apr 2010, Eduard Pascual wrote:
>
> Basically, most of the issues with headings boil down to a single fact: 
> the sectioning model is (probably needlessly) over-bloated. [...]
> 
> And now, in HTML5, not only have  been kept, but a plethora of new 
> elements: , , , , , , 
> ; and it even messes with . The justifications for 
>  (backwards compatibility, better transition, etc) are quite 
> sound; but the 7 new elements more than double the mess.

Another way to look at it is that the new elements simplify the markup 
authors have to use. Most of the new elements correspond to very commonly 
used class names.


> Actually, if we try to "implement" the outlining algorithm in the form 
> of selectors that match each level of headings we have: On the case that 
> the -only approach, selecting each level of heading requires a list 
> of something raised to the n-th power selectors, where n is the heading 
> level minus one.

Not necessarily. We can fix Selectors to make this much shorter, in a way 
equivalent to what the spec says, for example using a pseudo-class like 
Mozilla's :-moz-any().


> On the case of a mixed approach, it is *absolutely* impossible to get 
> the headings properly matched with current selector technology.

Indeed. We can always improve that technology if that's a problem, though.

In practice it's not clear what the needs are here. I don't see most 
authors needing to select both / and / etc with the 
styles interacting. Do you have any concrete use cases in mind where this 
is a problem?


> My suggestion is to clean things a bit: consolidate the sectioning model 
> into a single element+attribute pair, like this:
>  stays as is.
>  becomes 
>  becomes 
>  becomes 
>  becomes  (and the former is defined
> in the compatibility section as equivalent to the later, because it is
> the only element of the sectioning model that already exists in
> previous versions of HTML).
> I'm not sure about what should be done with , , and
> , but I hope this is a good place to discuss it ;-)

I don't understand what problem this solves. All its seems to do is make 
the language more verbose.


> This yields several advantages:
> 1) The styling issue improves drastically: any pre-HTML5 will
> understand this (IE would require a bit of javascript anyway) out of
> the box:
> h1 { styling for top-level }
> section h1 { styling for second-level }
> section section h1 { styling for third-level }
> and so on, for as many levels as you need.

If you want to target older UAs, you can just use - with 
, instead of relying on the automatic sizing of .


> 2) All of a sudden, something like See
> also some indirectly related links here... becomes
> possible, plus easy to style, and works happily with the outlining
> algorithm.

Isn't that a negative, rather than a positive?


> 3) Future needs will become easier to solve on future versions of the 
> specification, and with significantly smaller costs: for example, let's 
> assume a new sectioning element such as  becomes a 
> widespread need (it would already make sense on sites like web-mail 
> services, discussion boards, bug-trackers, and some others...). So a new 
> crouton on the soup, which would be treated quite like a generic  
> by pre-HTML6 (or 7, or whatever) browsers. Now, with the 
> +attribute approach, we'd get something like  kind="attachment">: that'd would still work with the outlining algoryth 
> (it could be treated as generic section), it's styling will work 
> smoothly, etc.

Given how often we add new sectioning elements, I don't think that's 
something to worry about optimising for. At least not in favour of a 
simple language.


On Sat, 1 May 2010, Eduard Pascual wrote:
>
> It's not a matter of saving a few characters here and there.

Well, that was more or less the reasoning behind having these elements in 
the first place, so it is a _bit_ about that. :-)


> The very purpose of  and its friends is to implement explicit 
> sectioning on HTML, so there is no need to rely on error-prone, 
> painful-to-maintain implicit -based sectioning. However, the spec 
> recommends still using  anyway, to ensure backwards compatibility. 
> The compatibility goal itself is a quite good thing but, on this case, 
> it not only destroys the primary purpose of the feature, but makes 
> things even worse: having to state the same thing (the sectioning of the 
> document) twice (with the sectioning elements and with the numbered 
> headings) doubles the chance to introduce errors, and doubles the effort 
> required to maintain the content.

Yeah, but it's only an issue during the transition period.


> In summary: the +attribute approach solves all the issues the
> current model solves

Not all of them; the main problem was that using  made ugly 
documents that are a mess to maintain.


> provides better (backward and forward) compatibility

It provides no better backwards compatibility unless you are relying on 
CSS, and the forward-compatibili

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/2/10, Garrett Smith  wrote:
> On 8/2/10, And Clover  wrote:
>> On 08/02/2010 09:57 PM, Garrett Smith wrote:
>>
[...]

> ({}).hasOwnProperty.call(document.links, "0");
>
> - and resulting true in IE.
>
> However, that hasOwnProperty check does not always true for

...does not always result `true for...

> collections. As seen in the previous example I posted, for property P,
> [[HasProperty]] resulted false when there is a property P. Once again,
> this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
> object]
>

That was not clear, I meant that [[HasProperty]] resulted false and
[[Get]], via property accessors. resulted in the element being
retrieved.

Garrett

Re: [whatwg] Proposal for Web Storage expiration

2010-08-02 Thread Nicholas Zakas

Yes, for IndexDB I think having a per-storage area expiration date completely 
makes sense. Do you expect that IndexedDB will become a successor to 
sessionStorage/localStorage? My belief is that the simple key-value store 
paradigm would still end up being the default client-side data storage utility, 
and would therefore benefit from having a per-key expiration time to mimic 
cookie usage.

To be clear, I think there should be expiration for all forms of client-side 
data storage, and adding it to one doesn't seem like a reason to not add it to 
all.

-Nicholas

__
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Jonas Sicking
Sent: Monday, August 02, 2010 2:10 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas  wrote:
> If a site could create multiple Storage areas, then I would agree that 
> per-item expiration wouldn't be necessary and we could get along fine with 
> per-storage expiration. However, that's not the case, and the expiration use 
> case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

> Having every developer that wants to expire data write his or her own code 
> seems extremely wasteful to me. Why ask people to reinvent the same 
> functionality over and over again? Whether or not cookies are a good model to 
> follow, the expiration functionality is what makes auth sequences using them 
> feasible.
>
> I'd defer to those who know on implementation details, but this doesn't seem 
> like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/2/10, And Clover  wrote:
> On 08/02/2010 09:57 PM, Garrett Smith wrote:
>
>> Can it be argued as to what "integer index" means? And what is a "string
>> index"?
>
> Good catch, that's pretty ambiguous language. Browsers implement this as
> if "integer index" were equal to the term "array index" defined section
> 15.4 of ECMA262 (that is an unsigned 32-bit integer other than
> (1<<32)-1, expressed in simplest-possible decimal form), and "string
> index" meaning any other index.
>

Not exactly.

An array's `length` is 1 greater than the largest index in the array;
represented as uint internally. The largest possible array index is
2^32 - 2. ES5 specification says this a bit differently:

| A property name P (in the form of a String value) is
| an array index if and only if ToString(ToUint32(P)) is
| equal to P and ToUint32(P) is not equal to 232-1

That could cover "integer index", but the remaining undefined is
"string index", which seems a paradoxical name, even for Java
programmers.

Suppose string index could be any other index. Or it could be any
index matching production for NAME.

But then, does that mean property access on an HTMLCollection can
never return undefined? Seems so; must be either `null` or an object.

If the a collection is spec'd to use specialized [[Get]] access, then
it may need to use catchalls. Again, browsers do use these in some
cases and they aren't specified.

> The paragraph should be updated to explicitly reference this; probably
> the language about square brackets should be dropped too, as it seems to
> represent a misunderstanding of exactly how the ECMAScript
> square-bracket and dot operators actually work.
>

> Whether a property name is an "array index" or not is an unrelated issue

Depends. If a specialized [[Get]] implemented as a catchall, then the
browsers do some checking.

A specialized [[Get]] may be interfering with array generics working
with IE host object collections. It may have been that it was too
complicated and that the developers decided that it was easier to fail
fast by throwing "JScript object expected'.

Again, on that error, if `ho` is a host object, then the behavior in
IE <= 8 for `[].slice.call( ho )` is "JScript object expected." IE
operation sees that the context -- the `this`value -- is not a JScript
object and then aborts prematurely, without trying. It could be that
the attempt to slice the object could actually succeed, as: -
  "0" in ho && "length" in ho

- is true.

> to the matter of how the property value is retrieved. OK, you can't use
> the direct dot syntax on an array index purely as a grammatical manner,
> but . and [] aren't the only way to access properties. (eg.
> document.links.hasOwnProperty('0').)
>

That shows that `hasOwnProperty` is present on the object and that
calling it returns true where there.

For compatibility with IE, a layer of indirection may be used:

({}).hasOwnProperty.call(document.links, "0");

- and resulting true in IE.

However, that hasOwnProperty check does not always true for
collections. As seen in the previous example I posted, for property P,
[[HasProperty]] resulted false when there is a property P. Once again,
this time with hasOwnProperty, I see a result in Firefox 3.6: [false,
object]

javascript: var result =
  [
  ({}).hasOwnProperty.call(document.forms[0], "0"),
  typeof document.forms[0][0]
  ];

 alert( result )

HTML5 also codifies a common form memory leak as "past names map".

Both of those oddities were explained more here:

However, AFAIK, HTML5 does not specify the catchall behavior for the
approach for specialized property access seen there.

Does a collection have element properties?  (and by "element", I do
not mean Element, but indexed/keyed item that represents an object in
the collection.

If it does, then that's a lot easier. Spec'd specialized behavior for
property accessors can be removed; as that behavior is already defined
by ECMA-262. The only change could be to allow for "integer index"
access to return `undefined`, as it currently does in most browsers.

If any collection does not have element properties, then it is
necessary to define "integer index" and "string access", at least for
that collection.

Most collections appear to have element properties and so I can't see
any reason for not specifying that. I recall raising discussion of
property access on collections over a year ago, before writing the
article I've linked above.

Garrett

Re: [whatwg] Race condition in media load algorithm

2010-08-02 Thread Chris Pearce


 On 2/08/2010 9:17 p.m., Ian Hickson wrote:

On Mon, 2 Aug 2010, Chris Pearce wrote:

There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the rest of the
resource selection algorithm asynchronously.

Not quite. It awaits a stable state and then runs a synchronous section,
which means that it will run the subsequent steps as soon as the current
task has finished, before anything else that is queued.



Ah, I see. My understanding of the processing model was incomplete, 
thanks for clarifying!


All the best,
Chris Pearce.

Re: [whatwg] [canvas] getContext & multiple contexts

On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
> 
> A while ago questions came up in the WebGL WG about using a canvas with 
> multiple rendering contexts, and synchronization issues that arise 
> there. Here's our suggested change to getContext.

This seems overly complex. I've gone for a somewhat simpler approach, 
which basically makes  fail getContext() if you call it with a 
context that isn't "compatible" with the last one that was used, as 
defined by a registry of contexts types. Currently, only '2d' and '3d' are 
defined in this registry, and they are not defined as compatible.

> It essentially allows for multiple contexts but adds no synchronization 
> primitives other than the requirement that rendering must be visible to 
> all contexts (that is, that they're rendered to the same destination 
> space).

Having 3D and 2D contexts rendering to the same space -- especially given 
getImageData() and the like -- seems like an interoperability nightmare.

> This also adds the 'attributes' parameter which can customize the 
> context that's created, as defined by the context itself.  WebGL has its 
> own context attributes object, and I'd suggest that the 2D context gain 
> at least an attribute to specify whether the context should be opaque or 
> not; but that's a separate suggestion from the below text.

I haven't added this. Could you elaborate on why this is needed? What 
happens if the method is invoked agains with different parameters?

It seems far preferable to have this on the API rather than as part of the 
getContext() method.

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

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread And Clover


On 08/02/2010 09:57 PM, Garrett Smith wrote:


Can it be argued as to what "integer index" means? And what is a "string index"?


Good catch, that's pretty ambiguous language. Browsers implement this as 
if "integer index" were equal to the term "array index" defined section 
15.4 of ECMA262 (that is an unsigned 32-bit integer other than 
(1<<32)-1, expressed in simplest-possible decimal form), and "string 
index" meaning any other index.


The paragraph should be updated to explicitly reference this; probably 
the language about square brackets should be dropped too, as it seems to 
represent a misunderstanding of exactly how the ECMAScript 
square-bracket and dot operators actually work.


Whether a property name is an "array index" or not is an unrelated issue 
to the matter of how the property value is retrieved. OK, you can't use 
the direct dot syntax on an array index purely as a grammatical manner, 
but . and [] aren't the only way to access properties. (eg. 
document.links.hasOwnProperty('0').)


--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread Jonas Sicking

On Fri, Jul 30, 2010 at 2:46 PM, Alex Russell  wrote:
> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking  wrote:
>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson  wrote:
>>>
>>> The e-mails quoted below consist of the salient points of this thread:
>>>
>>> On Fri, 23 Apr 2010, David Bruant wrote:

 Make that HTMLCollection (and all HTML*Collection, as a consequence of
 inheritence of HTMLCollection) inherit from the ECMAScript Array
 prototype. This way, it will make available all Array extra methods
 (forEach, map, filter...) added in ECMAScript5 (and next versions which
 should go in the same direction).

 As far as I know, adding this won't break any existing code. The
 semantics of a Collection and the way it is used is very close from
 ECMAScript Arrays. I don't think that the notion of "live object" and
 ECMAScript Array are incompatible either. Once again, I am talking about
 ECMAScript binding. I have no intention to touch the HTMLCollection
 interface or other languages bindings.
>>>
>>> On Sun, 25 Apr 2010, J Z wrote:

 If HTMLCollection was inheriting from Array, and methods like `forEach`,
 `map`, etc. were to operate on a live object, there would definitely be
 undesired consequences. We can see this in, say, Firefox (which allows to
 set [[Prototype]] of `HTMLCollection` to `Array.prototype`):

 HTMLCollection.prototype.__proto__ = Array.prototype;

 document.getElementsByTagName('div').forEach(function(el) {
   el.parentNode.removeChild(el); // doesn't work as expected
 });

 // turning live collection into static array fixes this
 Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
   el.parentNode.removeChild(el);
 });
>>>
>>> On Sat, 24 Apr 2010, David Bruant wrote:

 I think I can take your point as a "pro" more than a "con", because in
 ES5, right before the definition of each array extra method, a paragraph
 like the following can be found :

 "The range of elements processed by forEach is set before the first call
 to callbackfn. Elements which are appended to the array after the call
 to forEach begins will not be visited by callbackfn. If existing
 elements of the array are changed, their value as passed to callback
 will be the value at the time forEach visits them; elements that are
 deleted after the call to forEach begins and before being visited are
 not visited."

 This point is confirmed by every algorithm where the length is "saved"
 once for all before the loop and not got from the .length property each
 time.
>>>
>>> On Mon, 26 Apr 2010, Erik Arvidsson wrote:
 On Sun, Apr 25, 2010 at 01:07, David Bruant wrote:
 > Le 25/04/2010 00:39, J Z a écrit :
 >>
 >> I have thought a lot about weirdnesses that people could think about
 >> like trying to assign a value to the HTMLCollection (divs[14] =
 >> myOtherDiv), but once again, it wouldn't be more allowed than it
 >> currently is (I have no idea of what happens today, but if an error
 >> is thrown in a for-loop, it should throw an error as well in a call
 >> within a forEach).
 >
 > How would destructive methods like `push` or `sort` behave? Would
 > `document.body.childNodes.push(document.createTextNode('foo'))` append
 > text node to a body element? Or would it be a noop?
 >
 > That is actually a very good point. It think that the behavior should
 > be exactly the same as "an equivalent without array methods". (this
 > point of my proposal would need to be made completly explicit for each
 > method)

 One way to solve this could be to split Array into two interfaces. One
 to be used with immutable array like objects and one to use to mutate
 objects. Then we could apply the immutable array like interface to
 NodeList and its related interfaces. The benefit of doing that is that
 NodeList.prototype.push would be undefined instead of failing when
 called.
>>>
>>> On Mon, 26 Apr 2010, David Flanagan wrote:

 Rather that trying to make DOM collections feel like arrays, how about
 just giving them a toArray() method?  This makes it clear that a
 collection is not an array, but clearly defines a way to obtain an
 array.  Clever implementors might even be able to optimize common
 uses-cases using some kind of copy-on-write strategy so that toArray()
 doesn't involve memory allocation and copying.

 Of course, trying to teach programmers when they ought to call toArray()
 and when it is not necessary is another matter.  Perhaps calling the
 method snapshot() and focusing on the live vs. static distinction
 instead of the fake array vs. true array distinction would invite less
 misuse.

 Or we can just leave the DOM as it is and get used to calling the
 equivalent of Prototype's $

Re: [whatwg] Race condition in media load algorithm

On Mon, 2 Aug 2010, Boris Zbarsky wrote:
> On 8/2/10 3:11 PM, Ian Hickson wrote:
> > > How are we defining "current asynchronous task" and "finish"?
> > 
> > In terms of the event loop algorithm:
> > 
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2
> 
> Ah, I see.  Is the note there about synchronous sections having no 
> side-effects something that is true by default due to the way 
> synchronous sections are used in the specification?

Yeah. It's intended to help keep the ways to implement this somewhat open.

> > > How does this setup handle cases when the "current asynchronous task"
> > > spins the event loop, if at all?
> > 
> > The spinning of the event loop is also defined in terms of the event loop
> > in a manner that strictly defines this:
> > 
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop
> 
> I'm not sure I follow the steps here, actually.  Just to make sure I do
> understand
> 
> Say I have a task T in the event queue.  Task T begins some algorithm that has
> a synchronous section, then spins the event loop. If I understand the steps
> in #processing-model-2 correctly, the synchronous sections would run after
> task T completes, not while task T is spinning the event loop?

The synchronous section would run as soon as the task span the event loop. 
Spinning the event loop is defined essentially as being equivalent to 
breaking the original task in two, one that does everything up to spinning 
the event loop, and one that does everything after spinning the event 
loop. You are effectively waiting for some condition to become true and 
then queueing a task to run the continuation of the algorithm. It's just 
more convenient to write the algorithms as one long set of steps rather 
than having split them up into multiple algorithms that invoke each other 
and pass state around.

> Or does "stop the currently running task" in #spin-the-event-loop imply 
> a jump to step 2 of the algorithm under #processing-model2?

Yes.

> (Note: I still have a problem with the way "pause" is defined here, but 
> I've raised that before, I believe.)

I think we all have a problem with "pause", but I don't know what we can 
do about it. I don't have any pending feedback from you on this topic, as 
far as I can tell.

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

Re: [whatwg] Proposal for Web Storage expiration

2010-08-02 Thread Jonas Sicking

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas  wrote:
> If a site could create multiple Storage areas, then I would agree that 
> per-item expiration wouldn't be necessary and we could get along fine with 
> per-storage expiration. However, that's not the case, and the expiration use 
> case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

> Having every developer that wants to expire data write his or her own code 
> seems extremely wasteful to me. Why ask people to reinvent the same 
> functionality over and over again? Whether or not cookies are a good model to 
> follow, the expiration functionality is what makes auth sequences using them 
> feasible.
>
> I'd defer to those who know on implementation details, but this doesn't seem 
> like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread Oliver Hunt


On Aug 2, 2010, at 12:57 PM, Garrett Smith wrote:
> I also linked to the old "catchalls" proposal earlier in the thread.
> That is because the host objects mentioned here have a specialized
> "catchall" behavior that isn't yet defined by any specification, so
> when the code has property access with an integer index, as: anObj[2]
> - then it's supposed to be the same as a  call to the `item` method.
> That mostly works, but isn't specified isn't completely and isn't
> completely interoperable due to variance in undefined vs null.
> 
> I noticed that rather than define catchall, HTML5 copied the old DOM text:
> 
> | In the ECMAScript DOM binding, objects implementing the
> | HTMLFormControlsCollection  interface must support being
> | dereferenced using the square bracket notation, such that dereferencing
> | with an integer index is equivalent to invoking the item() method with that
> | index, and such that dereferencing with a string index is equivalent to
> | invoking the namedItem() method with that index.
> 
> The problem with that is that property access doesn't do any
> typechecking, and so
>  obj[2]
> - is equivalent to:-
>  obj["2"]
> 
> Can it be argued as to what "integer index" means? And what is a "string 
> index"?

It does seem a little weird as EcmaScript does not distinguish between string 
and non-string property names, the special handling of "numeric" indices inside 
the [[GetOwnProperty]]/[[PutOwnProperty]] methods of those types that have 
special handling, in those types the special "numeric index" path is hit if the 
property name is an "Array index", which is defined as (pseudo code)

bool isArrayIndex(String property)
{
unsigned index = ToUint32(property);
return ToString(index) == property && index >= 0 && index < 0x; 
}

> Garrett

--Oliver

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/2/10, Garrett Smith  wrote:
> On 8/2/10, Oliver Hunt  wrote:
>>
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>>
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
 all array functions defined in ES5 are "generic" in that they work
 over any array-like object.
>>>
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>>
>> Uhhh, I have no idea what you're talking about -- there are no type
>> checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically
>> start
>> out like this:
>>
>
> [..]
>
> And they continue like this:
>
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
>
> Where "[something]" is replaced by "slice" in this case.
>
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>>
>
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it

Should be:
any object that is not defined by the specification.

I also linked to the old "catchalls" proposal earlier in the thread.
That is because the host objects mentioned here have a specialized
"catchall" behavior that isn't yet defined by any specification, so
when the code has property access with an integer index, as: anObj[2]
- then it's supposed to be the same as a  call to the `item` method.
That mostly works, but isn't specified isn't completely and isn't
completely interoperable due to variance in undefined vs null.

I noticed that rather than define catchall, HTML5 copied the old DOM text:

| In the ECMAScript DOM binding, objects implementing the
| HTMLFormControlsCollection  interface must support being
| dereferenced using the square bracket notation, such that dereferencing
| with an integer index is equivalent to invoking the item() method with that
| index, and such that dereferencing with a string index is equivalent to
| invoking the namedItem() method with that index.

The problem with that is that property access doesn't do any
typechecking, and so
  obj[2]
 - is equivalent to:-
  obj["2"]

Can it be argued as to what "integer index" means? And what is a "string index"?

Garrett

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread Oliver Hunt

On Aug 2, 2010, at 12:25 PM, Garrett Smith wrote:

> On 8/2/10, Oliver Hunt  wrote:
>> 
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>> 
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
 all array functions defined in ES5 are "generic" in that they work
 over any array-like object.
>>> 
>>> They're guaranteed to work over any array-like native JavaScript object.
>>> They're *not* guaranteed to work on host objects like the various node
>>> lists.
>> 
>> Uhhh, I have no idea what you're talking about -- there are no type checks
>> in any of the array prototype functions, they all operate in terms of
>> property access alone, all the methods we're talking about basically start
>> out like this:
>> 
> 
> [..]
> 
> And they continue like this:
> 
> "Whether the [something] function can be applied successfully to a
> host object is implementation-dependent."
> 
> Where "[something]" is replaced by "slice" in this case.
> 
>> Eg. "array-like" in the context of ES5 should be interpreted as "has a
>> property named 'length', the array methods will work on any type.
>> 
> 
> That is not true. ECMAScript has what is called "host object". A host
> is any ecmascript object that is not defined by the specification; it
> is not a user-defined object (because that explicitly defined to be a
> native object).
> 
> A host object may or may not be implemented as a native ECMAScript
> object. That leaves two types of host objects:
> 1) native
> 2) non-native
> 
> More on that:
> 
> 
> Nothing says that any of the various dom "collection" objects must be
> native object.
> 
> The W3C does not define an interface "collection"; The term itself
> comes from Microsoft IE 4, which predates the w3c DOM; hence the
> quotes around the term "collection".

I didn't say that Host Objects don't exist, i said that "array like" is 
equivalent basically "has a property named length"

Things like Array.prototype.splice not working "as expected" on a NodeList is 
because the numeric properties on the nodelist are essentially DontDelete(or 
configurable=false in es5)

If I define an Object with:
var o = {length:1};
Object.defineProperty(o, "0", {value: "foo", configurable: false});

Then do:
var result = Array.prototype.splice.call(o, 0)

result will be ["foo"], but the property will not have been removed from object 
o.

There is no part of the spec that performs a type check, being a Host Object 
does not get you out of the required behaviour of the Array methods.

The reason the behaviour of Host Objects is considered magic is not so that you 
can say a function doesn't need to work on them, it is _specifically_ to allow 
the behaviour shown by the DOM where you can have properties that are have the 
attributes writable=false, configurable=false, and yet can still change.  This 
is the basis of the Host Object exception.  No property on a non-Host Object 
can change if it is not writable, yet the DOM requires that there be objects 
that do just that.

That said there is also no way in which you can implement any of the live 
collection types using EcmaScript.

Re: IE + Array methods, for whatever reason the ES5 spec does have an addendum 
that allows an implementation to disallow array methods on host objects -- i 
think this was foolish as the specification of the array methods should behave 
exactly as they would with a object with equivalent properties and attributes.

--Oliver

Re: [whatwg] Race condition in media load algorithm


On 8/2/10 3:11 PM, Ian Hickson wrote:

How are we defining "current asynchronous task" and "finish"?


In terms of the event loop algorithm:


http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2


Ah, I see.  Is the note there about synchronous sections having no 
side-effects something that is true by default due to the way 
synchronous sections are used in the specification?



How does this setup handle cases when the "current asynchronous task"
spins the event loop, if at all?


The spinning of the event loop is also defined in terms of the event loop
in a manner that strictly defines this:


http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop


I'm not sure I follow the steps here, actually.  Just to make sure I do 
understand


Say I have a task T in the event queue.  Task T begins some algorithm 
that has a synchronous section, then spins the event loop.  If I 
understand the steps in #processing-model-2 correctly, the synchronous 
sections would run after task T completes, not while task T is spinning 
the event loop?  Or does "stop the currently running task" in 
#spin-the-event-loop imply a jump to step 2 of the algorithm under 
#processing-model2?


(Note: I still have a problem with the way "pause" is defined here, but 
I've raised that before, I believe.)


-Boris

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/2/10, Oliver Hunt  wrote:
>
> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>
>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>> all array functions defined in ES5 are "generic" in that they work
>>> over any array-like object.
>>
>> They're guaranteed to work over any array-like native JavaScript object.
>> They're *not* guaranteed to work on host objects like the various node
>> lists.
>
> Uhhh, I have no idea what you're talking about -- there are no type checks
> in any of the array prototype functions, they all operate in terms of
> property access alone, all the methods we're talking about basically start
> out like this:
>

[..]

And they continue like this:

"Whether the [something] function can be applied successfully to a
host object is implementation-dependent."

Where "[something]" is replaced by "slice" in this case.

> Eg. "array-like" in the context of ES5 should be interpreted as "has a
> property named 'length', the array methods will work on any type.
>

That is not true. ECMAScript has what is called "host object". A host
is any ecmascript object that is not defined by the specification; it
is not a user-defined object (because that explicitly defined to be a
native object).

A host object may or may not be implemented as a native ECMAScript
object. That leaves two types of host objects:
 1) native
 2) non-native

More on that:

Nothing says that any of the various dom "collection" objects must be
native object.

The W3C does not define an interface "collection"; The term itself
comes from Microsoft IE 4, which predates the w3c DOM; hence the
quotes around the term "collection".

>>
>> FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the
>> modern desktop browsers except for IE.
>>
>> It would be possible to specify that the native-JS object guarantee should
>> also extend to node lists. This would allow fast browser implementations
>> of the array-like methods to be used without having to copy to a new
>> Array. However this would still leave the method of calling them a little
>> ugly.
>
> As above there is no question of it being possible -- the spec behaviour
> makes no exceptions for host vs. native object types.  If IE has a bug, then
> IE has a bug, that doesn't change the spec.
>

IE does not have a bug. IE does not implement its host objects as
native ES objects. I proposed to change that by defining an interface
that would require that, as well as putting a definition of [[Get]]
property access on such objects in one place; not scattered through
various interfaces as they currently are and will continue to be
otherwise, with the proliferation of new indexed "collection" type
interfaces.

Garrett

Re: [whatwg] Race condition in media load algorithm

On Mon, 2 Aug 2010, Boris Zbarsky wrote:
> 
> So the model is that there are asynchronous tasks but there are also 
> things that run after the "current asynchronous task" finishes?

It's a little more detailed than that, but yes, that describes the event 
loop model.


> How are we defining "current asynchronous task" and "finish"?

In terms of the event loop algorithm:

   
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2


> How does this setup handle cases when the "current asynchronous task" 
> spins the event loop, if at all?

The spinning of the event loop is also defined in terms of the event loop 
in a manner that strictly defines this:

   
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#spin-the-event-loop

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

Re: [whatwg] Please consider simplifying authoring guidance for the alt attribute

2010-08-02 Thread Ashley Sheridan

On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote:

> - search engines should generally ignore text in the alt attribute,
> but 
> evaluate the title attribute instead
> 
> Rationale:
> 
> 4.8.1.1.12 says: "A corollary to this is that the alt attribute's
> value 
> should never contain text that could be considered the image's
> caption, 
> title, or legend. It is supposed to contain replacement text that
> could 
> be used by users instead of the image; it is not meant to supplement
> the 
> image. The title attribute can be used for supplemental information."

What you said doesn't make sense. The alt text is to be used instead of
the image, and the title is for supplemental content. Therefore, search
engines should use alt text, as that is what they are attempting to
convey in the lost (in the sense that search engines don't process
images like they do text) image. If they used the title, one can only
imagine the trouble.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Proposal for Web Storage expiration

2010-08-02 Thread Nicholas Zakas

If a site could create multiple Storage areas, then I would agree that per-item 
expiration wouldn't be necessary and we could get along fine with per-storage 
expiration. However, that's not the case, and the expiration use case is 
clearly already present.

Having every developer that wants to expire data write his or her own code 
seems extremely wasteful to me. Why ask people to reinvent the same 
functionality over and over again? Whether or not cookies are a good model to 
follow, the expiration functionality is what makes auth sequences using them 
feasible. 

I'd defer to those who know on implementation details, but this doesn't seem 
like a very hard problem to solve in a performant way.

-Nicholas

__
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: Scott Hess [mailto:sh...@google.com] 
Sent: Friday, July 30, 2010 5:05 PM
To: Nicholas Zakas
Cc: Jeremy Orlow; Alexandre Morgaut; whatwg@lists.whatwg.org; Jonas Sicking
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas  wrote:
> And I totally agree, this is not a strong security feature, and that's not
> the intent. The intent is just to give an extra measure of control of the
> lifetime of the data to bring Web Storage closer to being a replacement for
> a wider range of functionality that currently uses cookies.

I don't think this really follows.  Cookies were invented quite awhile
ago, and may not be a good model for development.  A reasonably small
dataset allows the client to expire cookies aggressively.  With large
local storage, doing per-item expiration is not a good idea - you do
not want your UA groveling through a gig of data you are not otherwise
using to expire a couple dozen items.  Per-database expiration might
make sense, because the expiration information could be stored in a
central location as a hint to the UA (if the site isn't going to use
the data after two weeks, might as well delete it).  Sites could
segment their expiration needs by using multiple data stores.

That said, idle storage is eventually going to be reclaimed anyhow, so
you could just ignore the problem.  Current storage proposals are much
richer than cookies, so the developer could just store dates alongside
their other data and make the decisions directly, no need for the
system to help.  Since the JavaScript accessing the data is executing
right next to the data, you don't have the latency issues
client/server communication introduces.  So long as expiration is a
SHOULD, its not clear to me that this idiom is powerful enough to
deserve footprint in the spec.

-scott

Re: [whatwg] Please consider simplifying authoring guidance for the alt attribute

2010-08-02 Thread Markus Ernst


Am 01.08.2010 11:43 schrieb Tantek Çelik:

http://wiki.whatwg.org/wiki/Img_Alt

I encourage fellow web authors to add opinions/comments.


My personal opinion on the alt attribute is that:
- it should only be used if the image is crucial for understanding the 
content, or for navigation (such as headline or link images or charts)

- it's absence should default to what is alt="" in HTML4
- search engines should generally ignore text in the alt attribute, but 
evaluate the title attribute instead


Rationale:

4.8.1.1.12 says: "A corollary to this is that the alt attribute's value 
should never contain text that could be considered the image's caption, 
title, or legend. It is supposed to contain replacement text that could 
be used by users instead of the image; it is not meant to supplement the 
image. The title attribute can be used for supplemental information."


The most common use cases of @alt are (at least as far as I know from my 
authoring practise):

- Insert the text contained in a headline or link image
- Insert an empty string to make the page validate
- Insert a short description of the image, preferably containing some 
keywords for search engines; sometimes the search engine aspect is 
weighted even higher than the contents of the image here


Only the first one of these use cases matches the gideline given in 
4.8.1.1.12. The second one is not harmful, exept some minimal bandwidth 
impact. But the third one is actually counterproductive with regard to 
accessibility.


An image which conveys information, if it is not a text replacement 
(such as a headline or link image), a corporate logo, or some kind of 
chart, is usually almost impossible to describe in a way that can't be 
considered the image's caption, title, or legend. Usually, the 
information conveyed by the image is either duplicated in the text that 
the image is associated to (or in it's caption or legend), or at all 
useless for anybody that does not see the image. Either way, the 
presence of an alt text does not provide useful information, but 
possibly confuses - specially if it is written with regard to search 
engines.


I am confident that declaring the alt attribute as optional would not 
only simplify the spec and validation, but also have no significant 
effect regarding accessibility, as poor authoring cannot really be 
prevented by structural means.


And I am also confident that if search engines ignored the alt 
attribute, and authors were encouraged to only insert alt text if helps 
to understand the content, this would have a positive effect on 
accessibility, as authors would be discouraged to put unnecessary 
information in the alt attribute for seo purposes, or duplicate the 
legend or caption (what I used to do before I read 4.8.1.1.12, because 
HTML4 seemed to require exactly this).

Re: [whatwg] "Content-Disposition" property for tags


On 8/2/10 1:15 PM, Aryeh Gregor wrote:

If you don't agree that this use-case is worth adding the feature for,
do you think that:
3) Something else?


For the use case your describe, it might just make more sense for 
browsers to support Content-Disposition on data: URIs directly 
somehow...  Maybe.


-Boris

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Aryeh Gregor

On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
 wrote:
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser.

If the author can predict that the user probably wants to do this
(like because they just clicked on a button that says "Save"), they
should be able to trigger it directly.  This isn't to say that the
user must be *forced* to do it -- if authors use this annoyingly,
browsers will compete on providing UI to avoid the annoyance.  As with
anything UI-related in specs, it would just serve as a hint or
guideline, not an iron-clad command that all browsers must obey to the
letter.

> I see where you're coming from, but we try not to force users to do things.

Let's say you have an image editor, written using canvas and whatnot.
You want to have similar UI to native image editors, and that includes
a "Save" button (probably adorned with a little picture of a 3.5"
floppy, which is amusing when you think about it).  Clicking the
"Save" button should pop up a dialog like in a native app, asking you
where to save it.  Currently this can be done, but you have to send a
request to the server and get a Content-Disposition: attachment
response.  Probably you have to do it in a hidden iframe so it doesn't
navigate the whole page, etc.  The request is for some feature to do
this without the rigamarole.

If you don't agree that this use-case is worth adding the feature for,
do you think that:

1) The status quo is fine: you should have to send a request to the
server to implement a "Save" button.  Offline image-editing apps don't
matter.  Probably not a popular attitude here.

2) You (the app author) shouldn't even be able to do that.  You should
have to say "Right-click and choose 'Save As'".  Except that of course
this is less convenient for the user, it takes up more space in the
UI, the option might not be named the same thing in all browsers, apps
might want to make right-click do something else so that context menus
don't work, there are plenty of platforms (like phones) where "right
click" doesn't even make sense, and in general the web platform makes
no UI guarantees at all.  So then we get multipage guides explaining
how to do it in a handful of popular browsers, with images and
step-by-step instructions like
, and unpopular
browser users get to figure it out themselves.

3) Something else?

All in all, this seems like a very straightforward, useful thing to
ask for.  Yes, users can do it through browser UI, but that doesn't
permit authors to present it in a consistent way, draw the user's
attention to it, put it where the user will expect it in context, etc.
 It's very similar to print(): of course the user can just hit Ctrl-P,
but some people are used to clicking "Print" buttons and will be
puzzled and unhappy if they don't find one.

Not everyone will try to think of alternative ways to perform a task
when their initial expectation fails.  That's the point where a lot of
people give up, or call their techy friends or relatives for help.
Many people use computers by rote, and don't know what to do when the
usual incantation fails.  Even for those of us who know better, it's
can be more convenient if the application has more control, so they we
don't *have* to manually click through menus when the app can do it
for us.

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Markus Ernst

Am 02.08.2010 18:21 schrieb Michael Kozakewich:

Dennis wrote:

Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.

People don't often like it when they're forced to do something. If they
want

to download it, they can select "Save Link As..." from their browser. If
they actually want to view it full-screen, they don't want to be forced to
download it.

I see where you're coming from, but we try not to force users to do things.
For the same reason, @target was removed from links.

But it has made it back into HTML5:
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element

I assume the reason is that some de-facto standards have established
that users have got used to.

One of them seems to be that clicking on an external link in a corporate
web site usually opens a new window or tab, whatever they set in their
browser prefs. Some users (like me) might forget to hold the ctrl key
because most corporate websites use target="_blank" anyway on all
external links, and get annoyed if the original page disappears and they
have to go back their session history.

Another de-facto expectation could be, that on a "download" page with
several links, they behave consistently, starting a download:

Press downloads

Portrait image (JPG)
My band (TIFF)
Curriculum vitae (PDF)
Discography (Excel File)

Every link is likely to invoke an other default action, which does not
seem consistent to me in this context - even if the downloading
journalist as an experienced user might be able to anticipate the action
based on the file type information in the brackets. Dennis' and Roger's
proposal would definitely be helpful here.

Re: [whatwg] "Content-Disposition" property for tags


Kornel Lesiński  wrote:


On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:
I agree that it's not good to force users in general. However, this  
attribute can be implemented only as a hint for browsers to display  
Open/Save dialog. Users wouldn't be forced to download the file, it  
would just be easier for them to download.


OTOH users may be annoyed when their browser isn't saving some types of  
documents by default (and whether certain type of file should be viewed  
inline or saved might depend on context, e.g., I may want to read PDF  
booklets in the browser, but would prefer to save PDF receipts and  
tickets).


If Content-Disposition was attribute on , then webmasters could  
easily offer right option (or both) where it makes sense.


Downloads can be "forced" already with Content-Disposition: attachment.  
It's just harder to do, and unfortunately that doesn't stop webmasters  
from trying. Popular PHP snippets for forcing download are among the  
most disgusting cargo-cult code I've ever seen — they're collection of  
self-contradictory and nonsensical HTTP headers, break caching and  
resuming, and often have security vulnerabilities.


It would be great if we could obsolete those scripts.



Thank you, this is exactly what I was trying to say. To "force" was maybe
the wrong word.

Re: [whatwg] "Content-Disposition" property for tags


Jeremy Keith  wrote:


Dennis wrote:

Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings.


Ah, I see. In that case, I fundamentally disagree with what you are  
asking for. Final control should be in the hands of the user, not the  
author.




Don't we already force many things on the user? Of course they can control
everything but nobody really knows what happens in the deep javascript of
any page except for the author or other authors if the JS is not  
obfuscated.


I want to force for convenience. This doesn't mean that web masters should  
not

provide a different way of visiting said content.

It was meant for download pages which often struggle with redirects which
directly open in the browser window.

Or picture galleries, saves you a few clicks. Or any other browser-opened
content like Adobe Flash, PDF of course, insert anything here.

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Tab Atkins Jr.

2010/8/2 Kornel Lesiński :
> Downloads can be "forced" already with Content-Disposition: attachment. It's 
> just harder to do, and unfortunately that doesn't stop webmasters from 
> trying. Popular PHP snippets for forcing download are among the most 
> disgusting cargo-cult code I've ever seen — they're collection of 
> self-contradictory and nonsensical HTTP headers, break caching and resuming, 
> and often have security vulnerabilities.
>
> It would be great if we could obsolete those scripts.

Indeed; I've used those code samples, and since the entire area is
basically voodoo to me, I still have no idea which headers I sent did
anything and which are useless or even harmful cruft.  In general,
even well-educated authors have no clue what they're doing here.

~TJ

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Kornel Lesiński

On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:

>>> Dennis wrote:
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
> 
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser. If
> they actually want to view it full-screen, they don't want to be forced to
> download it.
> 
> I see where you're coming from, but we try not to force users to do things.
> For the same reason, @target was removed from links.

I agree that it's not good to force users in general. However, this attribute 
can be implemented only as a hint for browsers to display Open/Save dialog. 
Users wouldn't be forced to download the file, it would just be easier for them 
to download.

OTOH users may be annoyed when their browser isn't saving some types of 
documents by default (and whether certain type of file should be viewed inline 
or saved might depend on context, e.g., I may want to read PDF booklets in the 
browser, but would prefer to save PDF receipts and tickets).

If Content-Disposition was attribute on , then webmasters could easily offer 
right option (or both) where it makes sense.

Downloads can be "forced" already with Content-Disposition: attachment. It's 
just harder to do, and unfortunately that doesn't stop webmasters from trying. 
Popular PHP snippets for forcing download are among the most disgusting 
cargo-cult code I've ever seen — they're collection of self-contradictory and 
nonsensical HTTP headers, break caching and resuming, and often have security 
vulnerabilities.

It would be great if we could obsolete those scripts.

-- 
regards, Kornel

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread Oliver Hunt

On Aug 2, 2010, at 7:36 AM, And Clover wrote:

> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>> all array functions defined in ES5 are "generic" in that they work
>> over any array-like object.
> 
> They're guaranteed to work over any array-like native JavaScript object. 
> They're *not* guaranteed to work on host objects like the various node lists.

Uhhh, I have no idea what you're talking about -- there are no type checks in 
any of the array prototype functions, they all operate in terms of property 
access alone, all the methods we're talking about basically start out like this:

1.  Let O be the result of calling ToObject passing the this value as the 
argument. 
2.  Let lenValue be the result of calling the [[Get]] internal method of O 
with the argument "length". 
3.  Let len be ToUint32(lenValue). 
4.  If IsCallable(callbackfn) is false, throw a TypeError exception. 
5.  If thisArg was supplied, let T be thisArg; else let T be undefined. 
6.  Let k be 0.
7.  Repeat, while k < len

Eg. "array-like" in the context of ES5 should be interpreted as "has a property 
named 'length', the array methods will work on any type.

> 
> FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the 
> modern desktop browsers except for IE.
> 
> It would be possible to specify that the native-JS object guarantee should 
> also extend to node lists. This would allow fast browser implementations of 
> the array-like methods to be used without having to copy to a new Array. 
> However this would still leave the method of calling them a little ugly.

As above there is no question of it being possible -- the spec behaviour makes 
no exceptions for host vs. native object types.  If IE has a bug, then IE has a 
bug, that doesn't change the spec.

--Oliver

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Tab Atkins Jr.

On Mon, Aug 2, 2010 at 9:21 AM, Michael Kozakewich
 wrote:
>>> Dennis wrote:
>>
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
>
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser. If
> they actually want to view it full-screen, they don't want to be forced to
> download it.
>
> I see where you're coming from, but we try not to force users to do things.
> For the same reason, @target was removed from links.

@target was not removed from links.  HTML4 Strict removed it, but
HTML5 rightly added it back because it has useful functionality.

~TJ

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Ashley Sheridan

On Mon, 2010-08-02 at 18:09 +0200, Dennis Joachimsthaler wrote:

> Ben Schwarz  wrote:
> 
> > I'm really not too sure what pre-existing problem this actually solves.
> > Given that a server sets the correct mime-types for a given resource, we
> > know what "type" it is already.
> 
> Yes, since we don't want to set MIME-Types. I want to be able to set
> what a file actually is. Is it a file which is supposed to be shown in
> the browser? Or is it an "attachment" (refering to the content-disposition
> setting)
> 
> > Setting the Content-disposition on the client side creates an annoying  
> > user
> > experience.
> 
> I don't think so. What would you rather have?
> 
> 
> (Please right click and save target as)
> 
> or
> 
> 
> 


Which can easily be done with sever-side code. It's still annoying for
the end user when things like this happen though. For example, who do
you know that hasn't turned off whatever PDF browser plugin has been
installed along with their Acrobat Reader?

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Jeremy Keith

Dennis wrote:
> Yes, but that wouldn't help since I want to force downloads regardless
> of the browser settings.

Ah, I see. In that case, I fundamentally disagree with what you are asking for. 
Final control should be in the hands of the user, not the author.

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Michael Kozakewich


Dennis wrote:

Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.


People don't often like it when they're forced to do something. If they want
to download it, they can select "Save Link As..." from their browser. If
they actually want to view it full-screen, they don't want to be forced to
download it.

I see where you're coming from, but we try not to force users to do things.
For the same reason, @target was removed from links.

Re: [whatwg] "Content-Disposition" property for tags


Ben Schwarz  wrote:


I'm really not too sure what pre-existing problem this actually solves.
Given that a server sets the correct mime-types for a given resource, we
know what "type" it is already.


Yes, since we don't want to set MIME-Types. I want to be able to set
what a file actually is. Is it a file which is supposed to be shown in
the browser? Or is it an "attachment" (refering to the content-disposition
setting)

Setting the Content-disposition on the client side creates an annoying  
user

experience.


I don't think so. What would you rather have?


(Please right click and save target as)

or



If I want to open a link in a new tab, window or download, I'll do it  
like I

have done for the last ten years—via a keyboard modifier or a contextual
menu.


No problem with what you want to have, but can't webmasters ALREADY set the
content-disposition? I just want to copy this functionality over to the  
client

to prevent that you always have to use a scripting language server-side.


On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith  wrote:


...

Re: [whatwg] "Content-Disposition" property for tags


Jeremy Keith  wrote:


Dennis wrote:

...
Hang on... isn't the mechanism for this already available via the "type"  
attribute?


For example:

Full size image


That wouldn't help in this case...


A browser could offer a preference setting, for example:

"Always download the following types of files, rather than opening in  
the browser:


* images[x]
* movies[  ]
...etc."


Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.

Re: [whatwg] Race condition in media load algorithm


On 8/2/10 5:17 AM, Ian Hickson wrote:

There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the rest of the
resource selection algorithm asynchronously.


Not quite. It awaits a stable state and then runs a synchronous section,
which means that it will run the subsequent steps as soon as the current
task has finished, before anything else that is queued.


So the model is that there are asynchronous tasks but there are also 
things that run after the "current asynchronous task" finishes?


How are we defining "current asynchronous task" and "finish"?  How does 
this setup handle cases when the "current asynchronous task" spins the 
event loop, if at all?


-Boris

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-08-02 Thread And Clover


On 07/30/2010 06:43 AM, Oliver Hunt wrote:

all array functions defined in ES5 are "generic" in that they work
over any array-like object.


They're guaranteed to work over any array-like native JavaScript object. 
They're *not* guaranteed to work on host objects like the various node 
lists.


FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on 
the modern desktop browsers except for IE.


It would be possible to specify that the native-JS object guarantee 
should also extend to node lists. This would allow fast browser 
implementations of the array-like methods to be used without having to 
copy to a new Array. However this would still leave the method of 
calling them a little ugly.


--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

Re: [whatwg] Please consider dropping the "sandbox" attribute from the element

2010-08-02 Thread Maciej Stachowiak

On Aug 1, 2010, at 6:59 PM, Tantek Çelik wrote:

> Summary: The new 'sandbox' feature on  should be considered
> for removal. It needs a security review, it will be a lot of work to
> implement properly, and may not actually solve the problem it is
> intending to solve.
> 
> More details here:
> 
> http://wiki.whatwg.org/wiki/Iframe_Sandbox
> 
> I encourage fellow web authors and browser implementers to add their
> opinions/comments to that wiki page.

As other have mentioned,  has been implemented in WebKit for 
some time. Additional points of information:

1) It's shipping in current versions of Safari and Chrome.
2) Security experts have reviewed it. @sandbox itself seems pretty solid, 
although there are possibly issues with related features such as 
text/html-sandboxed and @seamless.
3) Content has been built using it.
4) While it's unclear if  will work well for comments or other 
such cases of seamless untrusted content, it seems clearly useful for use cases 
like gadgets and ads.

While more security review is always welcome, it seems like the basic idea is 
solid, and it's demonstrably implementable. The initial patch implementing it 
for WebKit can be seen here: . This 
patch was 100k, but more than half of it is tests and the ChangeLog entry.

Regards,
Maciej

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Ben Schwarz

I'm really not too sure what pre-existing problem this actually solves.
Given that a server sets the correct mime-types for a given resource, we
know what "type" it is already.

Setting the Content-disposition on the client side creates an annoying user
experience.

If I want to open a link in a new tab, window or download, I'll do it like I
have done for the last ten years—via a keyboard modifier or a contextual
menu.

On Mon, Aug 2, 2010 at 8:31 PM, Jeremy Keith  wrote:

> Dennis wrote:
> > I have an idea which would be very cool for HTML5.
> >
> > Having a Content-Disposition property on  tags which does the same as
> > the HTTP Header.
> > For example changing the file name of the file to be downloaded or rather
> > have a image
> > file download rather than it being shown in the browser directly.
>
> Hang on... isn't the mechanism for this already available via the "type"
> attribute?
>
> For example:
>
> Full size image
>
> A browser could offer a preference setting, for example:
>
> "Always download the following types of files, rather than opening in the
> browser:
>
> * images[x]
> * movies[  ]
> ...etc."
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>
>

Re: [whatwg] "Content-Disposition" property for tags

2010-08-02 Thread Jeremy Keith

Dennis wrote:
> I have an idea which would be very cool for HTML5.
> 
> Having a Content-Disposition property on  tags which does the same as
> the HTTP Header.
> For example changing the file name of the file to be downloaded or rather
> have a image
> file download rather than it being shown in the browser directly.

Hang on... isn't the mechanism for this already available via the "type" 
attribute?

For example:

Full size image

A browser could offer a preference setting, for example:

"Always download the following types of files, rather than opening in the 
browser:

* images[x]
* movies[  ]
...etc."

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/

Re: [whatwg] Race condition in media load algorithm