Re: [whatwg] @sandbox and navigation top

[Adam Barth]

On Fri, Feb 12, 2010 at 11:48 PM, Michal Zalewski  wrote:
>> Can a frame in @sandbox ever navigation the top-level frame?  If not,
>> that would make it hard to use @sandbox to contain advertisements,
>> which want to navigate |top| when the user clicks on the ad.
>
> Ads would want to be able to do that, but user-controlled gadgets
> shouldn't. I suppose the top-level page should be able to specify, and
> the entire @sandbox chain would need to be traversed to make the call
> (so that @sandbox included on example.com that is prohibited from
> messing with the top-level frame can't just create a nested frame
> without the restriction, and bypass the check).
>
> I assume that chain-style checking is already a part of the spec, as
> we obviously don't want other restrictions to be removed in a similar
> manner?

Yes, the sandbox restrictions collect in subframes.

Perhaps we want an "allow-frame-busting" directive?  In the
implementation we have an "allow-navigation" bit that covers
navigation |top| as well as window.open, etc.  Maybe we want a more
general directive that twiddles this bit?

Adam

Re: [whatwg] @sandbox and navigation top

[Michal Zalewski]

> Can a frame in @sandbox ever navigation the top-level frame?  If not,
> that would make it hard to use @sandbox to contain advertisements,
> which want to navigate |top| when the user clicks on the ad.

Ads would want to be able to do that, but user-controlled gadgets
shouldn't. I suppose the top-level page should be able to specify, and
the entire @sandbox chain would need to be traversed to make the call
(so that @sandbox included on example.com that is prohibited from
messing with the top-level frame can't just create a nested frame
without the restriction, and bypass the check).

I assume that chain-style checking is already a part of the spec, as
we obviously don't want other restrictions to be removed in a similar
manner?

/mz

[whatwg] @sandbox and navigation top

[Adam Barth]

Can a frame in @sandbox ever navigation the top-level frame?  If not,
that would make it hard to use @sandbox to contain advertisements,
which want to navigate |top| when the user clicks on the ad.

Adam

Re: [whatwg] should async scripts block the document's load event?

[Steve Souders]

ASYNC should not block the onload event. Thinking of the places where 
ASYNC will be used, they would not want onload to be blocked.


-Steve

On 2/12/2010 11:50 AM, Jonas Sicking wrote:

It's a good point. Curious to hear what other people are thinking.

/ Jonas

On Fri, Feb 12, 2010 at 10:10 AM, Nicholas Zakas  wrote:
   

To me “asynchronous” fundamentally means “doesn’t block other things from
happening,” so if async currently does block the load event from firing then
that seems very wrong to me.



-Nicholas



__

Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"

Morpheus: "My beliefs do not require them to."



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Brian Kuhn
Sent: Friday, February 12, 2010 8:03 AM
To: Jonas Sicking
Cc: Steve Souders; WHAT Working Group
Subject: Re: [whatwg] should async scripts block the document's load event?



Right.  Async scripts aren't really asynchronous if they block all the
user-visible functionality that sites currently tie to window.onload.



I don't know if we need another attribute, or if we just need to change the
behavior for all async scripts.  But I think the best time to fix this is
now; before too many UAs implement async.



-Brian









On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking  wrote:

Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
load to start asap, but we don't want the load to hold up the load
event if all other resources finish loading before this one.

/ Jonas

On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders  wrote:
 

I just sent email last week proposing a POSTONLOAD attribute for scripts.

-Steve

On 2/10/2010 5:18 PM, Jonas Sicking wrote:
   

On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhnwrote:

 

No one has any thoughts on this?
It seems to me that the purpose of async scripts is to get out of the
way
of
user-visible functionality.  Many sites currently attach user-visible
functionality to window.onload, so it would be great if async scripts at
least had a way to not block that event.  It would help minimize the
affect
that secondary-functionality like ads and web analytics have on the user
experience.
-Brian

   

I'm concerned that this is too big of a departure from how people are
used to

Re: [whatwg] validationMessage

[Aryeh Gregor]

On Fri, Feb 12, 2010 at 1:40 AM, Peter Kasting  wrote:
> I am explicitly opposed to the UA showing validation messages to the user.
>  I do not think HTML5 should attempt to address use cases where the author
> wants the UA to show the messages.

I strongly disagree.  Boilerplate browser-provided UI for common types
of requirements would be a really useful feature here.  It drastically
reduces the work needed for authors to do common types of validation
that are more complicated than "max" and "min", like type="email" and
such, and should improve correctness and user experience.  (Reference:
)

If authors wanted to write complicated scripts to do validation, they
could already do so.  One of the most important features here is that
you *don't* need to write any script to get a full validation system,
including UI.

On Fri, Feb 12, 2010 at 9:23 AM, Tab Atkins Jr.  wrote:
> When I use a jQuery validation plugin for my forms today, I pretty
> much always rely on the default error message that the library
> provides.  It's rare for me to override it; I typically only provide
> messages when I'm specifying a custom validation that doesn't have a
> message (as the default error message for a custom validation rule is
> far too generic).
>
> So yes, I'd use validationMessage in my own UI.  It's easier, as it
> lets me be completely agnostic about the actual error, and just plug
> in whatever the error is into my custom UI.

Okay -- I defer to your much greater experience in this realm.

> I don't know that I've ever seen a validated form rely solely on
> non-textual UI for anything, except possibly the failure to fill out a
> required field (and even then, there's a message somewhere on the page
> explaining that all the fields with a red border are required or
> whatever).
>
> If that were to happen, though, an artificial string would be
> appropriate.  Ian, do you think this needs to be explicitly stated?

It's probably not necessary unless a browser actually wants to do this.

Re: [whatwg] should async scripts block the document's load event?

[Jonas Sicking]

It's a good point. Curious to hear what other people are thinking.

/ Jonas

On Fri, Feb 12, 2010 at 10:10 AM, Nicholas Zakas  wrote:
> To me “asynchronous” fundamentally means “doesn’t block other things from
> happening,” so if async currently does block the load event from firing then
> that seems very wrong to me.
>
>
>
> -Nicholas
>
>
>
> __
>
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>
> 
>
> From: whatwg-boun...@lists.whatwg.org
> [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Brian Kuhn
> Sent: Friday, February 12, 2010 8:03 AM
> To: Jonas Sicking
> Cc: Steve Souders; WHAT Working Group
> Subject: Re: [whatwg] should async scripts block the document's load event?
>
>
>
> Right.  Async scripts aren't really asynchronous if they block all the
> user-visible functionality that sites currently tie to window.onload.
>
>
>
> I don't know if we need another attribute, or if we just need to change the
> behavior for all async scripts.  But I think the best time to fix this is
> now; before too many UAs implement async.
>
>
>
> -Brian
>
>
>
>
>
>
>
>
>
> On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking  wrote:
>
> Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
> load to start asap, but we don't want the load to hold up the load
> event if all other resources finish loading before this one.
>
> / Jonas
>
> On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders  wrote:
>> I just sent email last week proposing a POSTONLOAD attribute for scripts.
>>
>> -Steve
>>
>> On 2/10/2010 5:18 PM, Jonas Sicking wrote:
>>>
>>> On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhn  wrote:
>>>

 No one has any thoughts on this?
 It seems to me that the purpose of async scripts is to get out of the
 way
 of
 user-visible functionality.  Many sites currently attach user-visible
 functionality to window.onload, so it would be great if async scripts at
 least had a way to not block that event.  It would help minimize the
 affect
 that secondary-functionality like ads and web analytics have on the user
 experience.
 -Brian

>>>
>>> I'm concerned that this is too big of a departure from how people are
>>> used to

Re: [whatwg] isindex as a parser macro

[Jonas Sicking]

On Fri, Feb 12, 2010 at 5:49 AM, Henri Sivonen  wrote:
>  4) Disparity with document.createElement("isindex");
>  5) Disparity with XHTML.

For what it's worth, I couldn't really care less about these two.
Making these work isn't a goal to me, people should be using s
instead.

/ Jonas

Re: [whatwg] should async scripts block the document's load event?

[Nicholas Zakas]

To me "asynchronous" fundamentally means "doesn't block other things
from happening," so if async currently does block the load event from
firing then that seems very wrong to me.

 

-Nicholas

 

__

Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Brian Kuhn
Sent: Friday, February 12, 2010 8:03 AM
To: Jonas Sicking
Cc: Steve Souders; WHAT Working Group
Subject: Re: [whatwg] should async scripts block the document's load
event?

 

Right.  Async scripts aren't really asynchronous if they block all the
user-visible functionality that sites currently tie to window.onload.

 

I don't know if we need another attribute, or if we just need to change
the behavior for all async scripts.  But I think the best time to fix
this is now; before too many UAs implement async.

 

-Brian

 

 

 

 

On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking 
wrote:

Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
load to start asap, but we don't want the load to hold up the load
event if all other resources finish loading before this one.

/ Jonas


On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders 
wrote:
> I just sent email last week proposing a POSTONLOAD attribute for
scripts.
>
> -Steve
>
> On 2/10/2010 5:18 PM, Jonas Sicking wrote:
>>
>> On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhn  wrote:
>>
>>>
>>> No one has any thoughts on this?
>>> It seems to me that the purpose of async scripts is to get out of
the way
>>> of
>>> user-visible functionality.  Many sites currently attach
user-visible
>>> functionality to window.onload, so it would be great if async
scripts at
>>> least had a way to not block that event.  It would help minimize the
>>> affect
>>> that secondary-functionality like ads and web analytics have on the
user
>>> experience.
>>> -Brian
>>>
>>
>> I'm concerned that this is too big of a departure from how people are
>> used to

[whatwg] :valid / :invalid only works in forms

[Erik Arvidsson]

At the moment an input element needs to part of a form and have a name
attribute for the CSS pseudo classes :valid and :invalid to be
applied. [1] These limitations forces people to make their DOM more
complicated just to be able to use these pseudo classes. It might have
made sense to have these limitations in a world where JavaScript was
not available but in many modern web apps there is no need for forms
nor name attributes.

Can we please remove these limitations?

Erik Arvidsson


[1] https://bugs.webkit.org/show_bug.cgi?id=34733#c7 (included below
for completeness)

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#association-of-controls-and-forms
> Constraint validation: If an element has no form owner, it is barred
> from constraint validation.

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#naming-form-controls
> Constraint validation: If an element does not have a name attribute
> specified, or its name attribute's value is the empty string, then
> it is barred from constraint validation.

http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes
> :valid
> The :valid pseudo-class must match all elements that are candidates for
> constraint validation and that satisfy their constraints.
>
> :invalid
> The :invalid pseudo-class must match all elements that are candidates
> for constraint validation but that do not satisfy their constraints.

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#candidate-for-constraint-validation
> A listed form-associated element is a candidate for constraint
> validation except when a condition has barred the element from
> constraint validation.

Re: [whatwg] Error: Stray doctype.

[Philip Taylor]

On Fri, Feb 12, 2010 at 4:08 PM, Dean Edwards  wrote:
> http://html5.validator.nu/?doc=http://www.whatwg.org/specs/web-apps/current-work/multipage/

Oops, looks like a consequence of moving the multipage script to a
server with a different version of lxml. Fixed.

-- 
Philip Taylor
exc...@gmail.com

[whatwg] Error: Stray doctype.

[Dean Edwards]

http://html5.validator.nu/?doc=http://www.whatwg.org/specs/web-apps/current-work/multipage/

-dean

Re: [whatwg] should async scripts block the document's load event?

[Brian Kuhn]

Right.  Async scripts aren't really asynchronous if they block all the
user-visible functionality that sites currently tie to window.onload.

I don't know if we need another attribute, or if we just need to change the
behavior for all async scripts.  But I think the best time to fix this is
now; before too many UAs implement async.

-Brian





On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking  wrote:

> Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
> load to start asap, but we don't want the load to hold up the load
> event if all other resources finish loading before this one.
>
> / Jonas
>
> On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders 
> wrote:
> > I just sent email last week proposing a POSTONLOAD attribute for scripts.
> >
> > -Steve
> >
> > On 2/10/2010 5:18 PM, Jonas Sicking wrote:
> >>
> >> On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhn  wrote:
> >>
> >>>
> >>> No one has any thoughts on this?
> >>> It seems to me that the purpose of async scripts is to get out of the
> way
> >>> of
> >>> user-visible functionality.  Many sites currently attach user-visible
> >>> functionality to window.onload, so it would be great if async scripts
> at
> >>> least had a way to not block that event.  It would help minimize the
> >>> affect
> >>> that secondary-functionality like ads and web analytics have on the
> user
> >>> experience.
> >>> -Brian
> >>>
> >>
> >> I'm concerned that this is too big of a departure from how people are
> >> used to

Re: [whatwg] validationMessage

[Tab Atkins Jr.]

On Thu, Feb 11, 2010 at 9:29 PM, Aryeh Gregor  wrote:
> Do you know of any actual authors who would want to use
> validationMessage?  If there are any authors here who would want to
> use the validation API with their own UI, would you want to use
> validationMessage or write your own messages?  I wouldn't be likely to
> write my own UI at all, so I'm not the best person to have an opinion
> here.

When I use a jQuery validation plugin for my forms today, I pretty
much always rely on the default error message that the library
provides.  It's rare for me to override it; I typically only provide
messages when I'm specifying a custom validation that doesn't have a
message (as the default error message for a custom validation rule is
far too generic).

So yes, I'd use validationMessage in my own UI.  It's easier, as it
lets me be completely agnostic about the actual error, and just plug
in whatever the error is into my custom UI.

> More generally, however, who says the UA will provide actual text for
> all validation errors?  I'm not sure what a concrete example would be,
> not being particularly good at UI, but I could imagine UAs using some
> non-textual cue if you try to submit a form with a missing required
> input, say.  They could provide some artificial string in that case,
> though, I guess.

I don't know that I've ever seen a validated form rely solely on
non-textual UI for anything, except possibly the failure to fill out a
required field (and even then, there's a message somewhere on the page
explaining that all the fields with a red border are required or
whatever).

If that were to happen, though, an artificial string would be
appropriate.  Ian, do you think this needs to be explicitly stated?

On Fri, Feb 12, 2010 at 12:40 AM, Peter Kasting  wrote:
> I am explicitly opposed to the UA showing validation messages to the user.
>  I do not think HTML5 should attempt to address use cases where the author
> wants the UA to show the messages.  I think the design should provide the
> author with return values that indicate what the results of validation were
> and the author should provide the rest of the UI.  In other words, I am
> opposed to trying to solve use cases #1 and #2 above.  Any design that
> attempts to solve them is a mistake.  Please remove validationMessage from
> the spec.

I *strongly* disagree.  #1 is by far the MOST important use-case for
these features, in my opinion.  Without it, several of the new input
types and attributes are basically useless.

Just as important, requiring the author to handle the UI means that
accessibility will likely be impaired.  I'm very excited about the new
types and error messages making my forms significantly more
accessible.  When you can provide accessibility like this *for free*
with no author intervention, it's silly to pass up the opportunity.

~TJ

Re: [whatwg] isindex as a parser macro

[Henri Sivonen]

On Feb 12, 2010, at 15:49, Henri Sivonen wrote:

> Problems with the parser macro include:
> 1) Special memory management cases due to generated attributes (done and 
> broken several times).
> 2) Form submission changes required (not done yet).
> 3) Incompatibility with the W3C DOM Level 2 HTML test suite.
> 4) Disparity with document.createElement("isindex");
> 5) Disparity with XHTML.

6) Makes the parser layer sensitive to localization.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

[whatwg] isindex as a parser macro

[Henri Sivonen]

Given that all the top 4 engines generate a different DOM for isindex and 
arguably Gecko (with the old parser) is the most sane, why does the spec align 
with IE instead of Gecko? Could the spec please align with Gecko (with the old 
parser)?

Problems with the parser macro include:
 1) Special memory management cases due to generated attributes (done and 
broken several times).
 2) Form submission changes required (not done yet).
 3) Incompatibility with the W3C DOM Level 2 HTML test suite.
 4) Disparity with document.createElement("isindex");
 5) Disparity with XHTML.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] tag

[Ian Hickson]

On Fri, 15 Jan 2010, Bruno Harbulot wrote:
> 
> Whilst I'm very supportive of having a key-generation mechanism in the 
> browser, I'm now not entirely sure the  tag, at least as a 
> legacy of the Netscape  tag, is the correct approach.

Indeed. It's only in the spec because that's what browsers implement.


> More specifically:
> 
> 1. The more modern APIs (generateCRMFRequest on Firefox or 
> CertEnroll/XEnroll on Internet Explorer) appear to offer more options in 
> general, for example, where to store the private key, is it exportable, 
> etc. (I haven't looked in details, but I suspect it could be envisaged 
> to use some existing key material from a software store or smartcard 
> too, for example.) This raises the question as to whether a tag is 
> sufficient or appropriate to express what's required for a CA, or if an 
> API (and more programming) is required.
> 
> 2. The SPKAC format seems to be a legacy format. It doesn't really allow 
> to convey much information that CAs would expect, unlike other formats 
> used by the more modern APIs. Perhaps it would be better to use one of 
> the newer formats instead. This might break the compatibility with the 
> pre-HTML 5 use of  (maybe another name than  in HTML5 
> would be better?).

Agreed. I would encourage anyone interested in following up on this topic 
to write a specification for such an API and get it implemented in 
browsers. It doesn't have to be part of HTML, as it is really an 
independent specification.


> Of course, the other big question is whether it's worth trying to 
> standardise this  tag if there's no intent of support from major 
> browser vendors (I have IE in mind here).

Pages depend on one of two mechanisms. We can specify either one. The 
first is . The second is ActiveX and the Win32 API.

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

Re: [whatwg] The examples of the list attribute of the input element is incorrect

[Ian Hickson]

On Wed, 6 Jan 2010, Futomi Hatano wrote:
> 
> There is a example which shows how to mark up fallback contents of the 
> datalist element.
> 
> 
>  
>   Enter a breed:
>   
>  
>  
>   
>or select one from the list:
>
>  (none selected)
> Abyssinian
> Alpaca
> 
>
>   
>  
> 
> 
> I think that this example is incorrect. [...] But it does not work in 
> UAs which support the datalist element as expected (i.e. the suggests 
> are not shown.), because the option elements do not have a value 
> attribute.
>
> The spec says that a value attribute is required in the option element 
> for a suggestion. 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element

It doesn't say they have to have a value _attribute_, it says it has to 
have a value. "Value" in this context is defined:

   
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#concept-option-value

...as "The value of an option element is the value of the value attribute, 
if there is one, or the textContent of the element, if there isn't".

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

[whatwg] Disable Offline ApplicationCache programmatically?

[Markus Joschko]

Hi,
I recently studied the "Offline Web app" section to investigate
whether HTML5 is a viable replacement for the gears plugin.
Sadly it is lacking a lot of functionality that we need to bring our
application offline. Following things I miss most from the spec:

1) Enable/Disable applicationCache(group) programatically from client
side javascript
2) Add a specific header when resources are fetched for offline storage
3) Add/Control URLs dynamically to the applicationCache

While I can live without 3), let me explain what makes 1) and 2) so valuable:

We have a CMS driven application that should be available offline as
well. That is not just a couple of pages but a few hundred including
resources like PDFs and images. Now some pages also have parts with
dynamic data, which is only to be shown when online. But then it need
to be accurate.

So what I would need is the ability to fetch all pages listed in a
manifest to the client. But they should NOT be served from the cache
as long as the client is online.
As a result the user can see all the dynamic data within the pages when online.
That's different from the current behaviour: Once they are available
in the cache, they are served from the cache.
The easiest thing here would be to allow cache control via a
javascript. So a user can switch on the cached version when he is
offline.

To optimize the pages for offline mode (hide login/search boxes etc),
it would be helpful to have a header that tells the server when the
resources are fetched to be displayed offline.

Finally, 3) would allow for optimization when only a single resource
is updated on the server. With the given spec after a manifest update,
all referenced pages are checked for update. If I had control over the
applicationCache entries, I could expire just the one updated entry.

The current spec reads like it is targeting mainly use cases where
only a small initial frame of resources is needed and otherwise
javascript and databases are used to provide the offline behaviour.
However with relatively small changes it could serve other purposes as well.

Regards,

 Markus Joschko

Re: [whatwg] validationMessage

[Anne van Kesteren]

On Fri, 12 Feb 2010 08:05:54 +0100, Peter Kasting   
wrote:

On Thu, Feb 11, 2010 at 11:01 PM, Jonas Sicking  wrote:

Would be great if you could provide a reason why you feel this way.


Did the previous messages in the thread not say enough reasons?  Ian's
response was basically "then how would we solve use cases 1 and 2?" which
was why I was clarifying that I did not have an alternative solution, I  
felt that they are cases we should not be trying to solve.


You wrote in that thread:

This seems like an attempt to make life slightly easier on webpage 
authors by providing boilerplate UI if they don't want to write 
anything.  But I see that as a small benefit with significant edge 
cases.  Authors are already expected to supply the textual content inthe  
page, the text in alerts, etc., so providing the text in the"validation  
failed" UI doesn't seem that bad.  The UA can still dothings like turn  
fields red or add warning sign icons or something if itlikes.


Isn't the benefit rather big? I can just use  on my page  
and the user agent will take care of ensuring it is correct (on the client  
side) and provide the appropriate messages to the user in case the user  
made a mistake. Anything beyond that will require scripting which seems  
overkill for e.g. blog comments.


I'm not too convinced with #2 though so exposing the message is probably  
not needed. (And if the user agent can somehow provide a non-textual user  
interface for the above that should be allowed too.)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Removing multiple attribute from with selected files

[Ian Hickson]

On Sun, 13 Dec 2009, TAMURA, Kent wrote:
>
> What should happen to selected files in a case that a user selects 
> multiple files for  and then a script code 
> removes the multiple attribute from the input element?
> 
> - nothing, no change to the selected files and they will be submitted,
> - cleared, or
> - a single file remains

Either it's cleared or all but one file is removed, the spec doesn't say 
anything beyond saying that if the attribute is missing, no more than one 
file may be selected.

The UA is allowed to change the selected files more or less arbitrarily 
("on behalf of the user"), so it's not really clear what we should say 
beyond that. However, I'm happy to specify this in more detail if it turns 
out that this is necessary for interop.


On Mon, 14 Dec 2009, Ojan Vafai wrote:
> 
> This should be an invalid thing to do. Can we throw an exception in 
> addition to leaving the list of files untouched?

Throwing an exception for DOM changes that are otherwise allowed would be 
very unusual.


On Mon, 14 Dec 2009, Jonas Sicking wrote:
> 
> I'd really prefer to keep things simple here as I doubt that this is 
> something that anyone will ever do. Much less depend on a particular 
> behavior.

Famous last words in this world!

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

Re: [whatwg] Uploading directories of files

[Ian Hickson]

This thread (of which some especially salient points are included below) 
requested the addition of a feature or the codifying of a convention for 
uploading directory tree structures in .

I think that including relative directory paths with uploads is a quite 
reasonable feature. However, I don't think we really yet have good 
experience with what the right conventions should be. I would recommend 
that browser vendors experiment with this feature and report back their 
findings, so that we can converge on a proven convention.


On Thu, 10 Dec 2009, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote:
>
> Many sites allow you to upload multiple files, often images. HTML5 
> allows this via . This works well when your 
> files are all in one folder, but it may often be the case that files are 
> spread across sub-folders, and in this case you have to do multiple 
> transactions (or multiple  tags, which is just 
> awkward) to upload your files.
> 
> PROPOSAL: Allow a UA to recursively select and upload a directory of 
> files. How the UA chooses to modify the file picker dialog is outside 
> the scope of this spec, but for the sake of argument, assume that the UA 
> lets you pick a folder and say "upload all". Allow the UA to upload the 
> files in the folder, with the subdirectories included in the filename 
> with a directory separator.
> 
> E.g. assume I have:
> 
> C:\users\ian\a\b\1.jpg
> C:\users\ian\a\b\2.jpg
> C:\users\ian\a\c\3.jpg
> 
> If the user chooses "a", the UA should be allowed to send all three 
> files with filenames:
> 
> "a/b/1.jpg"
> "a/b/2.jpg"
> "a/c/3.jpg"
> 
> as it would for the existing  implementation, 
> with the addition of the directories and path separators (not full path, 
> just the directory the user chose and sub-paths.)

On Thu, 10 Dec 2009, Jonas Sicking wrote:
> 
> I don't think there is anything in the spec preventing you from doing 
> this right now. The fact that only files in the same folder can be 
> selected is a limitation in the implementation, not a limitation in the 
> spec.
> 
> The spec does require that only the leaf name, without any paths, are 
> submitted. Is that a problem?
> 
> I guess I'd be ok with changing the spec to allow more of the path to be 
> exposed. However that would mean that there is a mismatch between what 
> name is submitted and what name you'd get from input.files[n].name.

On Thu, 10 Dec 2009, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) 
wrote:
> 
> I think that the notion of allowing more of the path to be exposed and 
> reconciling that with .name is where the problem lies, and would like to 
> figure out if we could resolve that. I think that there is a case to be 
> made for including the paths -- e.g. if I'm uploading photos to flickr, 
> picasa, or facebook, I may have already organized them locally, there's 
> no reason that I shouldn't be able to maintain that structure when I 
> upload to the web application. The question is then how that gets 
> reconciled with input.files[n].name -- I would think it preferable if 
> .name also were allowed to contain that extra information -- currently 
> we say "The name of the file. There are numerous file name variations on 
> different systems; this is merely the name of the file, without path 
> information.". I guess I would propose that be changed to "The name of 
> the file. There are numerous file name variations on different systems; 
> this is merely the name of the file. If the user agent allows for files 
> from multiple directories to be selected and included in a single 
> FileList, path information may be included to distinguish between the 
> files, provided that such path information SHOULD NOT include 
> information about any path components that are common to all of the 
> Files in the FileList."

On Thu, 10 Dec 2009, Jonas Sicking wrote:
> 
> If we're going to expose a full or partial path, then I think we should 
> do that separately from the .name property. I'd rather keep the .name 
> strictly be the leaf name.

On Fri, 11 Dec 2009, Markus Ernst wrote:
> 
> If I understand you correctly, this would lead to differences in file 
> names based on the UA, and even based on the folder that the user 
> actually chose to upload. See your example:
> 
> C:\users\ian\a\b\1.jpg
> C:\users\ian\a\b\2.jpg
> C:\users\ian\a\c\3.jpg
> 
> 1. The user anually selects files 1.jpg and 2.jpg in directory b. The 
> resulting filename of the first file is "1.jpg".
> 
> 2. Tho other day the user does an update, but this time selects 
> directory b and does "upload all". Resulting filename: "b/1.jpg".
> 
> 3. For the next update the user wants to easily upload all 3 files, 
> which results in: "a/b/1.jpg".
> 
> 4. Then the same action is done from another computer with a different 
> UA, the file might again be named "1.jpg".

On Fri, 11 Dec 2009, Jeremy Orlow wrote:
> 
> Personally, I don't think the case Markus pointed out is at all a show 
> stopper.  In the case of images, the

Re: [whatwg] <% text %> and in corporate intranet html content

[Simon Pieters]

On Fri, 12 Feb 2010 03:10:32 +0100, Boris Zbarsky  wrote:


On 2/11/10 3:07 AM, Biju wrote:

the text inside<% and %>  may contain any number of percentage sign or
greater than sign,
as long as they dont make a "%>" pair.


OK


If you see  treat it like a HTML comment.
Again for this also a comment node will be created  in DOM,
and when its parent nodes .innerHTML is displayed the original content
will be shown with out altering.
the text inside  may contain any number of question mark or
greater than sign,
as long as greater than sign is enclosed in single quote or double  
quote.


Hmm.  So more or less faking PIs?


I agree that allowing  "?>"  part is weird, they should have done it
same way as "<% text %>"


I don't see why; for PIs the IE behavior actually sort of makes sense


PIs in SGML and XML are not sensitive to quote marks.

Also see  
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-September/012458.html


--
Simon Pieters
Opera Software