date:20110928


On 9/28/11 7:02 PM, Ian Hickson wrote:

There are specific problems in both those cases because of interaction
with the C++ layer, as far as I can tell.


Those are there, sure.  But they're not the only problems...


The pure JS side of things, which is all that is needed for what we're talking 
about here, needs
nothing more than just adding a prototype, something which is not only
well-supported by all browsers


I wouldn't call it "well" supported.

In particular proto chain changes can cause various deoptimizations to 
happen in JITs.



but defined in increasingly careful detail.


I'm not aware of anything that defines mutable prototype chains. 
Pointer please?  There has been desire to maybe standardize it in ES, 
but no real action yet.



Interoperability is only improving here, and there seems to be no
desire to remove it -- quite the opposite, we're actively working on
making it more useful for authors.


I'm not aware of any work to make changing the prototype chain more 
useful to anyone...



Using an attribute to declare the binding could work if we make its
value immutable or if we make changes to its value have no effect.


For use cases consisting of creating new or augmented widgets, that's fine
by me. We already have plenty of precedent for attributes whose changes do
nothing, for example

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components


On 9/28/11 6:54 PM, Ian Hickson wrote:

Yes, for instance. Basically any use cases that is about presentation
rather than logic.


Do such use cases need to expose new API on the element?

-Boris

Re: [IndexedDB] New version API checked in

2011-09-28 Thread Jonas Sicking

On Wed, Sep 28, 2011 at 3:55 PM, Israel Hilerio  wrote:
> On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
>> On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio 
>> wrote:
>> > On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
>> >> On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio
>> >> 
>> >> wrote:
>> >> > On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
>> >> >> Hi Everyone,
>> >> >>
>> >> >> I finally got around to updating the IndexedDB spec to the new
>> >> >> version
>> >> API!
>> >> >> Definitely a non-trivial change, so I'd love for people to have a
>> >> >> look at it to see if I messed anything up.
>> >> >>
>> >> >> I decided to go with the name "upgradeneeded" for the event fired
>> >> >> when a version upgrade is needed. I'm not terribly happy with the
>> >> >> name, but it does feel descriptive.
>> >> >>
>> >> >> I also went with integers (long long) for the version number. The
>> >> >> reason was that I wanted to avoid people passing strings like "1.10"
>> >> >> to the API since JS will automatically and silently convert that
>> >> >> to the number 1.1. This could lead to confusion since people might
>> >> >> think that "1.10" is a higher version than "1.9".
>> >> >>
>> >> >>
>> >> >> There were a few issues that came up during editing, mostly
>> >> >> related to edge cases that doesn't matter terribly much:
>> >> >>
>> >> >> * What to do if multiple different versions are opened at the same
>> time.
>> >> >> Consider the following scenario. A database with name "mydb" has
>> >> >> version 3. The following two calls happen almost at the same time:
>> >> >>
>> >> >> req1 = indexedDB.open("mydb", 4);
>> >> >> and
>> >> >> req2 = indexedDB.open("mydb", 5);
>> >> >>
>> >> >> It's clear that we should here fire a "upgradeneeded" event on
>> >> >> req2 and let it run a VERSION_CHANGE transaction to upgrade the
>> >> >> database to
>> >> version 5.
>> >> >> There are however two possible things we could do to req1.
>> >> >>
>> >> >> A) Immediately fail by firing an "error" event on req1.
>> >> >> B) Wait for req2 to attempt to upgrade the database version to 5.
>> >> >> Only once that succeeds fail req1 by firing an "error" event at it.
>> >> >> If req2 failed to upgrade the database (due to a aborted
>> >> >> transaction), then fire a "upgradeneeded" transaction on req1.
>> >> >>
>> >> >> This seems like a really rare edge case and I don't think it
>> >> >> matters much what we do. I chose to go with option B since it
>> >> >> results in the least amount of errors and it doesn't seem
>> >> >> particularly important to optimize for failing open calls quickly in 
>> >> >> this
>> rare situation.
>> >> >>
>> >> >> I don't think it matters much what we choose here. I think it's
>> >> >> very unlikely to matter in any real-world scenarios. I might even
>> >> >> be fine with letting implementations choose to go with either solution
>> here.
>> >> >>
>> >> >>
>> >> >> * What to do if indexedDB.open is called while a VERSION_CHANGE
>> >> >> transaction is pending, but the new call is for a higher version.
>> >> >> Consider the following scenario:
>> >> >>
>> >> >> 1. A database with name "mydb" and version 1 is currently open in tab
>> 1.
>> >> >> 2. Someone calls indexedDB.open("mydb", 2) in tab 2.
>> >> >> 3. The indexedDB implementation fires a "versionchange" event on
>> >> >> the open connection in tab 1 and waits for it to close. The
>> >> >> newVersion property of the event is set to 2.
>> >> >> 4. Someone calls indexedDB.open("mydb", 3) in tab 3.
>> >> >>
>> >> >> At this point there are at least two options:
>> >> >> A) Simply let the call in step 4 wait for the call in step 2 to
>> >> >> finish. Only after it has finished will we fire new events to
>> >> >> attempt an upgrade to version 3
>> >> >> B) Stall the upgrade two version 2 and instead start attempting an
>> >> >> upgrade to version 3. I.e. fire a new "versionchange" event on the
>> >> >> open connection in tab 1 (now with newVersion set to 3), and once
>> >> >> that connection is closed, fire a "upgradeneeded" event and start
>> >> >> a
>> >> VERSION_CHANGE transaction in tab 3.
>> >> >>
>> >> >> Option A basically makes us behave as if the call in step 4
>> >> >> happened after the VERSION_CHANGE transaction for the call in step
>> >> >> 2 had started. Option B almost makes us behave as if the calls in
>> >> >> step 2 and step 4 had happened at the same time (with the
>> >> >> exception that two "versionchange" events are fired).
>> >> >>
>> >> >> As with the previous issue I don't think it matters much what we
>> >> >> choose here. I think it's very unlikely to matter in any
>> >> >> real-world scenarios. I might even be fine with letting
>> >> >> implementations choose to go with either solution here.
>> >> >>
>> >> >>
>> >> >> * What to do if db.close() is called during the VERSION_CHANGE
>> >> >> transaction Calling db.close() during a VERSION_CHANGE transaction
>> >> >> somewhat similar to calling t

Re: [XHR2] Avoiding charset dependencies on user settings

2011-09-28 Thread Jonas Sicking

On Wed, Sep 28, 2011 at 2:54 AM, Henri Sivonen  wrote:
> On Wed, Sep 28, 2011 at 4:16 AM, Jonas Sicking  wrote:
>> So it sounds like your argument is that we should do  prescan
>> because we can do it without breaking any new ground. Not because it's
>> better or was inherently safer before webkit tried it out.
>
> The outcome I am suggesting is that character encoding determination
> for text/html in XHR should be:
>  1) HTTP charset
>  2) BOM
>  3)  prescan
>  4) UTF-8
>
> My rationale is:
>  * Restarting the parser sucks. Full heuristic detection and
> non-prescan  require restarting.
>  * Supporting HTTP charset, BOM and  prescan means supporting
> all the cases where the author is declaring the encoding in a
> conforming way.
>  * Supporting  prescan even for responseText is safe to the
> extent content is not already broken in WebKit.
>  * Not doing even heuristic detection on the first 1024 bytes allows
> us to avoid one of the unpredictability and
> non-interoperability-inducing legacy flaws that encumber HTML when
> loading it into a browsing context.
>  * Using a clamped last resort encoding instead of a user setting or
> locale-dependent encoding allows us to avoid one of the
> unpredictability and non-interoperability-inducing legacy flaws that
> encumber HTML when loading it into a browsing context.
>  * Using UTF-8 as opposed to Windows-1252 or a user setting or
> locale-dependent encoding as the last resort encoding allows the same
> encoding to be used in the responseXML and responseText cases without
> breaking existing responseText usage that expects UTF-8 (UTF-8 is the
> responseText default in Gecko).

Do we have any guesses or data as to what percentage of existing pages
would parse correctly with the above suggestion? If we only have
guesses, what are those guesses based on?

My concern is leaving large chunks of the web decoded incorrectly with
the above algorithm. My perception was that a very large number of
pages don't declare a charset in the 1-3 locations proposed above, and
yet aren't encoded in UTF8.

This article is over a year old at this point, but we still had less
than 50% of the web in UTF8 at that point.

http://googland.blogspot.com/2010/01/g-unicode-nearing-50-of-web.html

> What outcome do you suggest and why? It seems you aren't suggesting
> doing stuff that involves a parser restart? Are you just arguing
> against UTF-8 as the last resort?

I'm suggesting that we do the same thing for XHR loading as we do for
 loading. With exception of not ever restarting the parser.
The goals are:

* Parse as much of the HTML on the web as we can.
* Don't ever restart a network operation as that significantly
complicates the progress reporting as well as can have bad side
effects since XHR allows arbitrary headers and HTTP methods.

/ Jonas

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson  wrote:
> > On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson  wrote:
> > > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > > > >
> > > > > I think new elements are completely fine as long as they are 
> > > > > inheriting directly from HTMLElement. It's when we start dealing 
> > > > > with sub-typing HTMLTableElement and such is when they get into 
> > > > > trouble.
> > > >
> > > > New elements are not fine, for reasons that have been discussed in 
> > > > detail on this thread. You can't just dismiss those problems, they 
> > > > still exist.
> > >
> > > Can you tell me what those are? I am probably missing something.
> >
> > I already mentioned a bunch here:
> > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1703.html
> >
> > And Boris mentioned some here:
> > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1721.html
> > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1718.html
> 
> But... these are all when we are not directly sub-typing from 
> HTMLElement... Can you explain where there's a fallback problem with 
> custom elements that are inheriting directly from HTMLElement?

If an author invents a new element, it doesn't matter what it inherits 
from. It won't have fallback behaviour, it won't have semantics that can 
be interpreted by search engines and accessibility tools, it won't have 
default renderings, and it won't allow for validation to catch authoring 
mistakes. I don't see what inheritance has to do with anything here.

If you're not talking about my e-mail above but bz's first one, then the 
problems still exist, unless you're saying that an author shouldn't be 
allowed to create a custom submit button by inheriting from HTMLElement.

If you're talking about bz's second e-mail, then consider cases such as:

   Foo
Bar 

...vs:

   Foo
Bar 

> > I'm talking e.g. about people who want their s to look 
> > different based on whether it's on a touch device or a mouse device, 
> > or who want their layout to use one JS layout algorithm on portrait 
> > devices and another on landscape devices (and want to switch between 
> > them automatically when the user rotates the device).
> 
> You don't need transient behavior attachment in either case. For the 
> first case, all you need is a select-like widget that can sense a type 
> of a device.

The point is that the page just uses , and the style is changed in 
the style sheet.

> For the second one, it's more likely (and practical) to build a layout 
> system that knows how to accommodate multiple form factors, than to 
> expect an author to pick and choose from a bucket of layout engines and 
> (mis-)apply them for different form factors.

It's far more practical for an author to pick different layout tools in 
CSS, than it is for them to (mis-)build a layout system that can do 
multiple form factors.

> > You've listed use cases for them. I assume you are interested in 
> > addressing the use cases you listed...
> 
> Does my explanation above help you understand that they don't _have_ to 
> be thought of as decorators?

They don't have to be thought of as decorators, but solutions that don't 
make them decorators are IMHO fundamentally flawed.

The way the Web works is that we have split the logic (semantics) from the 
presentation (layout). The former is in the markup and in scripts in the 
markup. The latter is in the CSS layer and images and, potentially, 
scripts in the CSS. This allows authors to cleanly write logic that is 
independent of the presentation, it allows for features such as media 
queries and alternative style sheets, and it supports graceful fallback in 
legacy UAs, accessibility, processing in tools that don't care about the 
presentation layer (such as search engines) or that have their own (such 
as voice browsers), and allows for the presentation to be applied to many 
pages at once and changed on a whim, without having to do changes on every 
page. This is a well-established, successful model. We should continue to 
use it and support it.

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

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson  wrote:
>
> On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson  wrote:
> > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > > >
> > > > I think new elements are completely fine as long as they are
> > > > inheriting directly from HTMLElement. It's when we start dealing
> > > > with sub-typing HTMLTableElement and such is when they get into
> > > > trouble.
> > >
> > > New elements are not fine, for reasons that have been discussed in
> > > detail on this thread. You can't just dismiss those problems, they
> > > still exist.
> >
> > Can you tell me what those are? I am probably missing something.
>
> I already mentioned a bunch here:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1703.html
>
> And Boris mentioned some here:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1721.html
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1718.html

But... these are all when we are not directly sub-typing from
HTMLElement... Can you explain where there's a fallback problem with
custom elements that are inheriting directly from HTMLElement?

>
> > > > I am not going to recap what Boris already said in regard to
> > > > transitive APIs. It's a Fundamentally Bad Thing, and all existing
> > > > instances already in the platform are known/recognized mistakes.
> > >
> > > There are use cases for which it is not only not a bad thing, but a
> > > fundamental requirement.
> >
> > Can you help me understand these use cases?
>
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1722.html
>
>
> > Are you referring to the Layout Manager and the SVG Form Controls ones?
>
> Yes, for instance. Basically any use cases that is about presentation
> rather than logic.
>
>
> > Let's use this hypothetical Layout Manager for example:
> >
> > 
> >  content ...
> > 
> > ... content ...
> > 
> >
> > As an author of "x-panel", I certainly want to listen to media queries
> > and change the splitter from vertical to horizontal when there's not
> > enough space for horizontal splitting. And what I _don't_ want is some
> > other behavior bound instead to my panel and my behavior unbound.
>
> That's a new widget.

Yup.

>
> I'm talking e.g. about people who want their s to look different
> based on whether it's on a touch device or a mouse device, or who want
> their layout to use one JS layout algorithm on portrait devices and
> another on landscape devices (and want to switch between them
> automatically when the user rotates the device).

You don't need transient behavior attachment in either case. For the
first case, all you need is a select-like widget that can sense a type
of a device. For the second one, it's more likely (and practical) to
build a layout system that knows how to accommodate multiple form
factors, than to expect an author to pick and choose from a bucket of
layout engines and (mis-)apply them for different form factors.

>
>
> > Also, there's probably a class of use cases for pure-decorators that are
> > added and removed transiently. That's not something Component Model
> > intends to tackle or block on.
>
> You've listed use cases for them. I assume you are interested in
> addressing the use cases you listed...

Does my explanation above help you understand that they don't _have_
to be thought of as decorators?

:DG<

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

Re: [File API] opaque string

2011-09-28 Thread Arun Ranganathan


On 8/31/11 3:45 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan 
 wrote:

On 8/14/11 6:00 AM, Anne van Kesteren wrote:

Why can you not use characters legally allowed in IRIs?


You can; they have to be escaped.


Yeah sure, every URI is an IRI, but that is not what I am asking.



I'm sorry, I think I'm not understanding you very clearly :(  The spec. 
currently specifies what can be an opaque string for blob: URIs.  Also, 
the spec. says that special characters (e.g. "#") should be escaped, so 
that the fragment isn't confused with characters in the opaque string 
production.  Other special characters should be escaped as well.  What 
problem have you identified with this, and what should we be doing 
instead to solve it?




I also noticed that "Use Cases for a New Scheme" is actually only 
listing requirements, not use cases. Maybe it should be renamed?




Agreed!  I will rename it "Requirements for a New Scheme."

-- A*

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Boris Zbarsky wrote:
> On 9/28/11 4:02 PM, Ian Hickson wrote:
> > I don't buy the argument that an element's API can't change.
> 
> To be more precise, such changes are very undesirable.
> 
> > We have many counter-examples already in the platform, for 
> > example's API can change dynamcially as it loads new plugins
> 
> This is actually a serious problem in practice, for both implementors 
> and consumers.  The behavior here is not very interoperable outside the 
> simplest cases last I checked.
> 
> > XBL in Mozilla causes elements to change APIs on the fly
> 
> We consider this to have been a design mistake that complicates both 
> implementation and use.  We have absolutely no desire to perpetuate it.

There are specific problems in both those cases because of interaction 
with the C++ layer, as far as I can tell. The pure JS side of things, 
which is all that is needed for what we're talking about here, needs 
nothing more than just adding a prototype, something which is not only 
well-supported by all browsers, but defined in increasingly careful 
detail. Interoperability is only improving here, and there seems to be no 
desire to remove it -- quite the opposite, we're actively working on 
making it more useful for authors.

IMHO this is the kind of thing that it makes imminent sense for a binding 
layer to make use of.

> > Furthermore, we cannot for performance reasons require that the 
> > component library be loaded before the page is parsed, since that 
> > would mean that loading an HTML page would be blocked on loading a 
> > subresource. We already have this problem with both style and scripts, 
> > and it is a performance nightmare.
> 
> I agree that it can cause performance problems, but as you note we 
> already have this with

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson  wrote:
> > On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > >
> > > I think new elements are completely fine as long as they are 
> > > inheriting directly from HTMLElement. It's when we start dealing 
> > > with sub-typing HTMLTableElement and such is when they get into 
> > > trouble.
> >
> > New elements are not fine, for reasons that have been discussed in 
> > detail on this thread. You can't just dismiss those problems, they 
> > still exist.
> 
> Can you tell me what those are? I am probably missing something.

I already mentioned a bunch here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1703.html

And Boris mentioned some here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1721.html
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1718.html


> > > I am not going to recap what Boris already said in regard to 
> > > transitive APIs. It's a Fundamentally Bad Thing, and all existing 
> > > instances already in the platform are known/recognized mistakes.
> >
> > There are use cases for which it is not only not a bad thing, but a 
> > fundamental requirement.
> 
> Can you help me understand these use cases?

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1722.html


> Are you referring to the Layout Manager and the SVG Form Controls ones?

Yes, for instance. Basically any use cases that is about presentation 
rather than logic.


> Let's use this hypothetical Layout Manager for example:
> 
> 
>  content ...
> 
> ... content ...
> 
> 
> As an author of "x-panel", I certainly want to listen to media queries
> and change the splitter from vertical to horizontal when there's not
> enough space for horizontal splitting. And what I _don't_ want is some
> other behavior bound instead to my panel and my behavior unbound.

That's a new widget.

I'm talking e.g. about people who want their s to look different 
based on whether it's on a touch device or a mouse device, or who want 
their layout to use one JS layout algorithm on portrait devices and 
another on landscape devices (and want to switch between them 
automatically when the user rotates the device).

This is purely presentational and should be triggered from CSS.


> Also, there's probably a class of use cases for pure-decorators that are 
> added and removed transiently. That's not something Component Model 
> intends to tackle or block on.

You've listed use cases for them. I assume you are interested in 
addressing the use cases you listed...

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

RE: [IndexedDB] New version API checked in

2011-09-28 Thread Israel Hilerio

On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
> On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio 
> wrote:
> > On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
> >> On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio
> >> 
> >> wrote:
> >> > On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
> >> >> Hi Everyone,
> >> >>
> >> >> I finally got around to updating the IndexedDB spec to the new
> >> >> version
> >> API!
> >> >> Definitely a non-trivial change, so I'd love for people to have a
> >> >> look at it to see if I messed anything up.
> >> >>
> >> >> I decided to go with the name "upgradeneeded" for the event fired
> >> >> when a version upgrade is needed. I'm not terribly happy with the
> >> >> name, but it does feel descriptive.
> >> >>
> >> >> I also went with integers (long long) for the version number. The
> >> >> reason was that I wanted to avoid people passing strings like "1.10"
> >> >> to the API since JS will automatically and silently convert that
> >> >> to the number 1.1. This could lead to confusion since people might
> >> >> think that "1.10" is a higher version than "1.9".
> >> >>
> >> >>
> >> >> There were a few issues that came up during editing, mostly
> >> >> related to edge cases that doesn't matter terribly much:
> >> >>
> >> >> * What to do if multiple different versions are opened at the same
> time.
> >> >> Consider the following scenario. A database with name "mydb" has
> >> >> version 3. The following two calls happen almost at the same time:
> >> >>
> >> >> req1 = indexedDB.open("mydb", 4);
> >> >> and
> >> >> req2 = indexedDB.open("mydb", 5);
> >> >>
> >> >> It's clear that we should here fire a "upgradeneeded" event on
> >> >> req2 and let it run a VERSION_CHANGE transaction to upgrade the
> >> >> database to
> >> version 5.
> >> >> There are however two possible things we could do to req1.
> >> >>
> >> >> A) Immediately fail by firing an "error" event on req1.
> >> >> B) Wait for req2 to attempt to upgrade the database version to 5.
> >> >> Only once that succeeds fail req1 by firing an "error" event at it.
> >> >> If req2 failed to upgrade the database (due to a aborted
> >> >> transaction), then fire a "upgradeneeded" transaction on req1.
> >> >>
> >> >> This seems like a really rare edge case and I don't think it
> >> >> matters much what we do. I chose to go with option B since it
> >> >> results in the least amount of errors and it doesn't seem
> >> >> particularly important to optimize for failing open calls quickly in 
> >> >> this
> rare situation.
> >> >>
> >> >> I don't think it matters much what we choose here. I think it's
> >> >> very unlikely to matter in any real-world scenarios. I might even
> >> >> be fine with letting implementations choose to go with either solution
> here.
> >> >>
> >> >>
> >> >> * What to do if indexedDB.open is called while a VERSION_CHANGE
> >> >> transaction is pending, but the new call is for a higher version.
> >> >> Consider the following scenario:
> >> >>
> >> >> 1. A database with name "mydb" and version 1 is currently open in tab
> 1.
> >> >> 2. Someone calls indexedDB.open("mydb", 2) in tab 2.
> >> >> 3. The indexedDB implementation fires a "versionchange" event on
> >> >> the open connection in tab 1 and waits for it to close. The
> >> >> newVersion property of the event is set to 2.
> >> >> 4. Someone calls indexedDB.open("mydb", 3) in tab 3.
> >> >>
> >> >> At this point there are at least two options:
> >> >> A) Simply let the call in step 4 wait for the call in step 2 to
> >> >> finish. Only after it has finished will we fire new events to
> >> >> attempt an upgrade to version 3
> >> >> B) Stall the upgrade two version 2 and instead start attempting an
> >> >> upgrade to version 3. I.e. fire a new "versionchange" event on the
> >> >> open connection in tab 1 (now with newVersion set to 3), and once
> >> >> that connection is closed, fire a "upgradeneeded" event and start
> >> >> a
> >> VERSION_CHANGE transaction in tab 3.
> >> >>
> >> >> Option A basically makes us behave as if the call in step 4
> >> >> happened after the VERSION_CHANGE transaction for the call in step
> >> >> 2 had started. Option B almost makes us behave as if the calls in
> >> >> step 2 and step 4 had happened at the same time (with the
> >> >> exception that two "versionchange" events are fired).
> >> >>
> >> >> As with the previous issue I don't think it matters much what we
> >> >> choose here. I think it's very unlikely to matter in any
> >> >> real-world scenarios. I might even be fine with letting
> >> >> implementations choose to go with either solution here.
> >> >>
> >> >>
> >> >> * What to do if db.close() is called during the VERSION_CHANGE
> >> >> transaction Calling db.close() during a VERSION_CHANGE transaction
> >> >> somewhat similar to calling transaction.abort(). At least in the
> >> >> sense that in neither case does it make sense for
> >> >> IDBFactorySync.open/IDBFactory.open to complete successfu

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson  wrote:
>
> On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> >
> > I think new elements are completely fine as long as they are inheriting
> > directly from HTMLElement. It's when we start dealing with sub-typing
> > HTMLTableElement and such is when they get into trouble.
>
> New elements are not fine, for reasons that have been discussed in detail
> on this thread. You can't just dismiss those problems, they still exist.

Can you tell me what those are? I am probably missing something.

>
>
> > I am not going to recap what Boris already said in regard to transitive
> > APIs. It's a Fundamentally Bad Thing, and all existing instances already
> > in the platform are known/recognized mistakes.
>
> There are use cases for which it is not only not a bad thing, but a
> fundamental requirement.

Can you help me understand these use cases?

Are you referring to the Layout Manager and the SVG Form Controls ones?

I think you inserted a use case there, which is theming Layout
Managers and/or SVG form controls. And I believe you have the approach
backwards. From author's perspective, they want the widgets to manage
the styling, not the outer document. Let's use this hypothetical
Layout Manager for example:

 content ...

... content ...

As an author of "x-panel", I certainly want to listen to media queries
and change the splitter from vertical to horizontal when there's not
enough space for horizontal splitting. And what I _don't_ want is some
other behavior bound instead to my panel and my behavior unbound.

And there's nothing wrong with allowing to style widgets according to
the theme of the site. That's what pseudos (or even more interesting
ideas, brainstormed at the Component Model meeting) are for.

Also, there's probably a class of use cases for pure-decorators that
are added and removed transiently. That's not something Component
Model intends to tackle or block on.

:DG<

Re: The algorithm to determine encoding for FileReader.readAsText() doesn't account for predefined content types

2011-09-28 Thread Arun Ranganathan


On 7/12/11 8:20 PM, Eli Grey wrote:

Shouldn't the algorithm for determining encoding for
FileReader.readAsText() take in account the type property's charset
parameter, if it exists? (e.g. a blob.type of
"text/plain;charset=UTF-8")



Greetings Eli,

Apologies for the long delay in response time.  This email message got 
lost somehow.


I think your suggestion is perfectly reasonable, and that the spec. 
should allow for the type property also including a charset component.  
If the two clash (namely, parameter with the charset production), we 
should defer to the parameter IMHO.


-- A*

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> 
> I think new elements are completely fine as long as they are inheriting 
> directly from HTMLElement. It's when we start dealing with sub-typing 
> HTMLTableElement and such is when they get into trouble.

New elements are not fine, for reasons that have been discussed in detail 
on this thread. You can't just dismiss those problems, they still exist.

> I am not going to recap what Boris already said in regard to transitive 
> APIs. It's a Fundamentally Bad Thing, and all existing instances already 
> in the platform are known/recognized mistakes.

There are use cases for which it is not only not a bad thing, but a 
fundamental requirement.

> There's the idea of "becomes" attribute that uses a somewhat similar 
> approach 
> (http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement).

Except for the part where you change the element name, that seems ok for 
the use cases that involve augmenting the logic and semantics of HTML 
(e.g. creating a new widget).

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

Re: [XHR2] Avoiding charset dependencies on user settings

2011-09-28 Thread Jonas Sicking

On Tue, Sep 27, 2011 at 11:10 PM, Anne van Kesteren  wrote:
> On Wed, 28 Sep 2011 03:16:46 +0200, Jonas Sicking  wrote:
>>
>> So it sounds like your argument is that we should do  prescan
>> because we can do it without breaking any new ground. Not because it's
>> better or was inherently safer before webkit tried it out.
>
> It does seem better to decode resources in the manner they are encoded.

I'm not sure I understand what you're saying here. If you're simply
saying that ideally we should always decode using the correct decoder,
then I agree.

>> I'd much rather first debate what behavior we want and if we can try
>> if that is safe.
>>
>> And we always have the option of only doing HTML parsing when
>> .responseType is set to "document". That is unlikely to break a lot of
>> content. And it saves users resources as it uses less memory.
>
> I think it should have the same behavior as XML. No reason to make it harder
> for HTML.

"same as XML" is a matter of definition though. We're doing all of the
following for XML:

* Using the same charset selection for XHR loading as for  loading.
* If we don't find any explicit charset in the http headers on in the
document body, we use UTF8
* If we don't find any explicit charset in the http header, we look
for a XML PI which contains a charset

It so happens that in XML all three of these are equivalent. For HTML
that is not the case. So which are you suggesting we do (I'm assuming
not the last one :) )?

/ Jonas

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

> transitive APIs.

Blergh! "TRANSIENT", not transitive.

:DG<

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson  wrote:
> On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
>>
>> Hi Ian! :)
>>
>> I already enumerated and hopefully addressed most of your concerns in
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html
>> and
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html,
>> but I am open to other ideas.

> You didn't address my concern, since my concern is that you're encouraging
> people to invent new elements. :-)

I think new elements are completely fine as long as they are
inheriting directly from HTMLElement. It's when we start dealing with
sub-typing HTMLTableElement and such is when they get into trouble.

I am not going to recap what Boris already said in regard to
transitive APIs. It's a Fundamentally Bad Thing, and all existing
instances already in the platform are known/recognized mistakes.

>
>   ...
>
> ...or, if the components are predeclared and you want something very
> terse:
>
>   ...
>

There's the idea of "becomes" attribute that uses a somewhat similar
approach (http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement).

>
>
>> So, we need a way to express in markup that a particular element is to
>> be created with a particular behavior. Since the tagName is the only
>> identifying property of a DOM element that can't be changed, this brings
>> us to... custom tag names.
>
> Custom tag names suffer from a much larger set of more serious problems
> than any of the solutions you have dismissed, as Boris and myself have
> pointed out just in the last day or so, and as others have pointed out in
> the past.

Custom tags are just a way to explain the sub-typing of DOM in markup.
If there's a better way to do it, let's.

:DG<

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components


On 9/28/11 4:02 PM, Ian Hickson wrote:

I don't buy the argument that an element's API can't change.


To be more precise, such changes are very undesirable.


We have many counter-examples already in the platform, for example's API
can change dynamcially as it loads new plugins


This is actually a serious problem in practice, for both implementors 
and consumers.  The behavior here is not very interoperable outside the 
simplest cases last I checked.



XBL in Mozilla causes elements to change APIs on the fly


We consider this to have been a design mistake that complicates both 
implementation and use.  We have absolutely no desire to perpetuate it.



Furthermore, we cannot for performance reasons require that the component
library be loaded before the page is parsed, since that would mean that
loading an HTML page would be blocked on loading a subresource. We already
have this problem with both style and scripts, and it is a performance
nightmare.


I agree that it can cause performance problems, but as you note we 
already have this with

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> 
> Hi Ian! :)
> 
> I already enumerated and hopefully addressed most of your concerns in 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html 
> and 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html, 
> but I am open to other ideas.

You didn't address my concern, since my concern is that you're encouraging 
people to invent new elements. :-)

> To recap 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1204.html, 
> the API surface (and thus the behavior) should be something an element 
> is born with. In other words, we need element behavior attachment 
> (http://wiki.whatwg.org/wiki/Behavior_Attachment).

I don't buy the argument that an element's API can't change. We have many 
counter-examples already in the platform, for example 's API 
can change dynamcially as it loads new plugins, anyone fiddling with 
prototypes can change many elements' APIs on the fly, XBL in Mozilla 
causes elements to change APIs on the fly, etc.

Furthermore, we cannot for performance reasons require that the component 
library be loaded before the page is parsed, since that would mean that 
loading an HTML page would be blocked on loading a subresource. We already 
have this problem with both style and scripts, and it is a performance 
nightmare. We're trying to work around it, by introducing features like

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components


On 9/28/11 2:55 PM, Dimitri Glazkov wrote:

So, this is really a parsing issue, right?


Parsing is one side of the issue, yes.  Only matters for declarative 
markup, of course.



Hixie, is this the same problem you were mentioned as "doesn't have
fallback behavior"?


I would assume Hixie is also worried about this case:

  

   var y = document.createElement("x-my-submit");
   document.getElementById("x").appendChild(y);
   // Can the form be submitted now?
   // What about in UAs that don't do component model?

  

which is the other part of the issue.

-Boris

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 11:30 AM, Boris Zbarsky  wrote:
> On 9/28/11 2:24 PM, Dimitri Glazkov wrote:
>>
>> Can you help me understand what the issues with fallback are?
>
> Sure.  If I want to attach a component to a  and to do that I have to
> write:
>
>  
>    Content
>  
>
> and somewhere before that point register that x-my-table should be treated
> as a table, then the whole thing falls apart in a UA that doesn't understand
> that registration.
>
> That is, this approach works if components are only used for situations that
> absolutely cannot work without the component available, as far as I can
> tell.

Ah, I understand! It's the same issue that you and Roland were
articulating in the other thread.

So, this is really a parsing issue, right? We have some invariants
about parsing context validity for a (small, but angry) subset of HTML
tags.

Hixie, is this the same problem you were mentioned as "doesn't have
fallback behavior"?

:DG<

>
> -Boris
>

Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 11:24 AM, Boris Zbarsky  wrote:
> On 9/28/11 2:12 PM, Dimitri Glazkov wrote:

 C.) Just don't allow components to be used in places that have a special
 content model.
>>>
>>> I prefer this one, because:
>>>
>>> 1. It is very simple.
>>>
>>> 2. It discourages people from using components in cases already handled
>>> by HTML.
>>
>> +1 as a first step. We can start with this and see how authors react.
>> I suspect that without actual running code and people trying things
>> out, we could be debating this for a very long time :)
>
> We already have authors requesting a way of binding a data-presentation
> component to a .  Which has a special content model.

Man, I keep forgetting to put your table-as-chart use case on the
wiki. I'll put it up tomorrow.

>
>> Also, the "content model" is a bit of a loaded term. It's only about
>> what browsers actually do. IRL, it's perfectly ok to plop an
>> element anywhere in your DOM tree. The only special-casing logic that
>> HTMLLiElement has is to deal with the rendering, as Morrita-san
>> already pointed out
>
> For , this is correct.
>
> For , you're screwed when using actual markup.  Take a look at
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1158 and tell me
> where the table row and cell went in the DOM, please.

Yeah... Table is a difficult one.

>
>> This is not the case for all elements though.
>
> Yes.
>
>> And we won't weed out all edge cases by principled studying. We gotta
>> start simple and let
>> peeps run code! :)
>
> While avoiding design decisions that permanently lock out things we already
> know people want to do.

No argument here, we need to fix the obvious boogers.

BTW, When I said "running code", I don't necessarily mean "shipping code".

I think it will be very useful to circulate a one-off build of
Chromium that supports component model and let bleeding-edgers have at
it.

:DG<

>
> -Boris
>
>
>

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components


On 9/28/11 2:24 PM, Dimitri Glazkov wrote:

Can you help me understand what the issues with fallback are?


Sure.  If I want to attach a component to a  and to do that I 
have to write:


  
Content
  

and somewhere before that point register that x-my-table should be 
treated as a table, then the whole thing falls apart in a UA that 
doesn't understand that registration.


That is, this approach works if components are only used for situations 
that absolutely cannot work without the component available, as far as I 
can tell.


-Boris

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 11:19 AM, Boris Zbarsky  wrote:
> On 9/28/11 2:08 PM, Dimitri Glazkov wrote:
>>
>> So, we need a way to express in markup that a particular element is to
>> be created with a particular behavior.
>
> Yes.
>
>> Since the tagName is the only
>> identifying property of a DOM element that can't be changed, this
>> brings us to... custom tag names.
>
> Or a declarative map from tagnames to behavior that you put in your .
>
> The benefit of the latter over custom tag names is that it degrades much
> better in both semantic and presentational terms when the component is not
> available (whether due to lack of UA support or due to it having gone 404).
>
> The drawback is when you only want to apply a component to _some_ of the
> nodes with that tag name in your DOM.
>
> I'm not sure yet that I see a way to do the latter without custom tag names,
> but the fallback story for them is just _terrible_  Going forward we can
> require a declarative map from custom tagnames to built-in tagnames to get
> fallback if the component fails to load or something, but that won't help
> UAs that don't support all the new stuff and that will hinder deployment by
> sites.

Can you help me understand what the issues with fallback are? Perhaps
we could look at them one by one and see whether a solution lies
somewhere in their midst?

>
> We could also consider ideas like a "component" attribute that cannot be
> removed and cannot be set outside the parser or something...  But that has
> its own issues.
>
> -Boris
>
>

Re: HTML element content models vs. components


On 9/28/11 2:12 PM, Dimitri Glazkov wrote:

C.) Just don't allow components to be used in places that have a special
content model.


I prefer this one, because:

1. It is very simple.

2. It discourages people from using components in cases already handled by HTML.


+1 as a first step. We can start with this and see how authors react.
I suspect that without actual running code and people trying things
out, we could be debating this for a very long time :)


We already have authors requesting a way of binding a data-presentation 
component to a .  Which has a special content model.



Also, the "content model" is a bit of a loaded term. It's only about
what browsers actually do. IRL, it's perfectly ok to plop an
element anywhere in your DOM tree. The only special-casing logic that
HTMLLiElement has is to deal with the rendering, as Morrita-san
already pointed out


For , this is correct.

For , you're screwed when using actual markup.  Take a look at 
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1158 and 
tell me where the table row and cell went in the DOM, please.



This is not the case for all elements though.


Yes.


And we won't weed out all edge cases by principled studying. We gotta start 
simple and let
peeps run code! :)


While avoiding design decisions that permanently lock out things we 
already know people want to do.


-Boris

[Bug 14329] New: I believe the possible DoS attack "message flooding" should be addressed i.e. a rogue domain uses "postMessage" to crash an implementation, crash another window etc. Jean-Lou Dupont

2011-09-28 Thread bugzilla

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14329

   Summary: I believe the possible DoS attack "message flooding"
should be addressed i.e. a rogue domain uses
"postMessage" to crash an implementation, crash
another window etc. Jean-Lou Dupont ht...@jldupont.com
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Messaging (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/postmsg/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
I believe the possible DoS attack "message flooding" should be addressed i.e.
a rogue domain uses "postMessage" to crash an implementation, crash another
window etc.

Jean-Lou Dupont
ht...@jldupont.com

Posted from: 173.178.98.120
User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko)
Chrome/15.0.874.21 Safari/535.2

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components


On 9/28/11 2:08 PM, Dimitri Glazkov wrote:

So, we need a way to express in markup that a particular element is to
be created with a particular behavior.


Yes.


Since the tagName is the only
identifying property of a DOM element that can't be changed, this
brings us to... custom tag names.


Or a declarative map from tagnames to behavior that you put in your .

The benefit of the latter over custom tag names is that it degrades much 
better in both semantic and presentational terms when the component is 
not available (whether due to lack of UA support or due to it having 
gone 404).


The drawback is when you only want to apply a component to _some_ of the 
nodes with that tag name in your DOM.


I'm not sure yet that I see a way to do the latter without custom tag 
names, but the fallback story for them is just _terrible_  Going 
forward we can require a declarative map from custom tagnames to 
built-in tagnames to get fallback if the component fails to load or 
something, but that won't help UAs that don't support all the new stuff 
and that will hinder deployment by sites.


We could also consider ideas like a "component" attribute that cannot be 
removed and cannot be set outside the parser or something...  But that 
has its own issues.


-Boris

Re: HTML element content models vs. components

On Tue, Sep 27, 2011 at 11:53 PM, Dominic Cooney  wrote:
>
> On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner
>  wrote:
> > Expanding on the general web component discussion, one area that hasn't been
> > touched on AFAIK is how components fit within the content model of HTML
> > elements.
> > Take for example a list
> > (http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-ul-element):
> >  and  have "Zero or more  elements" as content model, while 
> > is specified to only be usable within ,  and .
> > Now it is not inconceivable that someone would like to create a component
> >  that acts as a list item, but expands on it. In order to allow this,
> > the content model for , ,  would need to be changed to
> > accomodate this. I can see this happening in a few ways:
> >
> > A.) allow elements derived from a certain element to always take their place
> > within element content models.
> > In this case, only components whose host element is derived from  would
> > be allowed within , , , whether or not it is rendered (q.v.
> > the "Should the shadow host element be rendered?" thread on this ML).
> >
> > B.) allow all components within all elements.
> > While quite broad, this may be necessary in case the host element isn't
> > rendered and perhaps derivation isn't used. Presumably the shadow DOM in
> > this case contains one - or even several -  elements as topmost elements
> > in the tree.
> >
> > C.) Just don't allow components to be used in places that have a special
> > content model.
>
> I prefer this one, because:
>
> 1. It is very simple.
>
> 2. It discourages people from using components in cases already handled by 
> HTML.

+1 as a first step. We can start with this and see how authors react.
I suspect that without actual running code and people trying things
out, we could be debating this for a very long time :)

Also, the "content model" is a bit of a loaded term. It's only about
what browsers actually do. IRL, it's perfectly ok to plop an 
element anywhere in your DOM tree. The only special-casing logic that
HTMLLiElement has is to deal with the rendering, as Morrita-san
already pointed out
(http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLLIElement.cpp).
This is not the case for all elements though. And we won't weed out
all edge cases by principled studying. We gotta start simple and let
peeps run code! :)

:DG<

Behavior Attachment Redux, was Re: HTML element content models vs. components

> The way to solve this is not to change the content models, it's to use an
> actual and bind it to the component. We should not have authors
> inventing new elements. It doesn't have fallback behaviour, it doesn't
> have semantics that can be interpreted by search engines and accessibility
> tools, it doesn't have default renderings, it doesn't allow for validation
> to catch authoring mistakes, it simply isn't a good design.

Hi Ian! :)

I already enumerated and hopefully addressed most of your concerns in
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html
and http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html,
but I am open to other ideas.

At this point, custom tags seems to be the most straightforward way of
conveying how things should work. XBL2 doesn't offer any better ideas,
as explained below.

Per our use cases
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases), we need a way
to allow attached behaviors to change element's API surface by adding
new (or shadowing existing) members.

To recap
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1204.html,
the API surface (and thus the behavior) should be something an element
is born with. In other words, we need element behavior attachment
(http://wiki.whatwg.org/wiki/Behavior_Attachment).

Let's look at the behavior attachment options that XBL2 provides:
1) Attachment using
2) Attachment using CSS
3) Attachment using the DOM (ElementXBL.addBinding)

Clearly, CSS-based behavior attachment is transient. Additionally,
security experts tell us that CSS-based behavior attachment is a Bad
Idea (http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0699.html).
So we should nix that.

Similarly, we can't use selectors with , since they imply
that an element only has behavior when in the document tree, which
makes it transient. This limits 's "element" attribute to
only refer to tag names, since they are the only non-transient
identifying property of a DOM element, and such all-or-nothing knob is
way too large to be useful.

We can't use ElementXBL.addBinding either, since it clearly treats
behavior as something you can add and remove.

Alrighty. Now that we ran out of ways to attach behaviors to elements
using XBL2, let's step outside the box.

In abstract, we need a mechanism to bestow some properties on a DOM
element before it emerges from the construction site. That seems easy
-- just do something like this:

var elementWithBehavior = document.createElement('div',
newBehaviorImplementation); // HTMLDivElement +
"newBehaviorImplementation" => baby

Unfortunately, the parser has no clue about this secret sauce and the
behavior is easily lost in markup roundtrips (or while cloning):

var someOtherDiv = document.createElement('div');
someOtherDiv.appendChild(elementWithBehavior);
document.body.innerHTML = someOtherDiv.innerHTML;
var ohNoesJustAnOrdinaryDivAgain = document.body.firstChild;

So, we need a way to express in markup that a particular element is to
be created with a particular behavior. Since the tagName is the only
identifying property of a DOM element that can't be changed, this
brings us to... custom tag names.

:DG<

P.S. As an experiment for myself, I hacked together a poor-man's
extensible DOM prototype
(http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/scripts/base.js#L351),
then used it to build a non-trivial Web application (a WebKit
infrastructure project). In the process, I found the notion of
extending DOM objects extremely addictive (see
http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/scripts/ui/notifications.js
to get your first dose of the drug). This new world _feels_ right and
I refuse going back to the old one.

Re: Web Components use cases, was Re: Notes from a component model pow-wow

2011-09-28 Thread Charles Pritchard


On 9/27/2011 10:26 PM, Roland Steiner wrote:
On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard > wrote:


[...] 


We have an opportunity now to document the sub-elements of single
form controls.


That is certainly a very valid goal. For example, it would really be 
great if an author could create his/her own video element and be able 
to re-use parts of the built-in  controls. One way could be to 
assemble larger components from smaller ones, and make those 
accessible to derived components.


However, getting all vendors to agree on a unified set of controls and 
layouts for the various form and media elements will certainly take 
time, and IMHO is only possible when the need for such arises.


I'd like to start with HTML forms. I'd like to start with the controls 
that have already led to css attributes.


Think: -moz-appearance, -webkit-appearance.

We're discussing how authors may generate components: let's look at how 
vendors -already- generate and style components.


This document right here, showing webkit CSS definitions of HTML 
components is fantastic:

http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css

That document is easy to read and defines how WebCore displays HTML 
components.


It's been made compact, for efficiency, so selectors are grouped 
together, which hinders

readability, a little. But, it does show all sorts of selectors.

That document shows web components, with various elements exposed as 
needed by WebKit vendors.


Other examples of components, which, despite controversy in the specs 
process, still stand:

http://www.webkit.org/blog/363/styling-scrollbars/
https://developer.mozilla.org/En/CSS/%3A%3Aselection

Defining a new HTML component:
http://trac.webkit.org/wiki/Styling%20Form%20Controls




Until we can express what existing form controls do, I see no
compelling case to leap forward and try to express new components.


This I don't agree with. Authors currently can and do use various 
frameworks to create what are essentially components, e.g., layout 
managers - undaunted by the fact that the internal structure of, say, 
 isn't specced out.


Yes, they can use ARIA 1.0 to mark up those frameworks; they can use 
semantic HTML, and they can use polyfill methods.


I did not express myself well: I'm happy to see authors experiment, and 
I'm happy to see discussion. I don't want that to stop.


But for spec editing, use cases and browser vendors, focus should be on 
HTML 3.2 Forms.



It does seem plausible that these selectors, in context, can unify
CSS Element names and DOM Element ids.


I think that will be possible only in the simplest of cases. For more 
complex components I don't think there necessarily will be a 1:1 
mapping of a pseudo-element name to an actual element.


I'd like to focus on the simplest of cases: HTML Forms.
From there, we might find standard means of building more complex 
components.


Whatever complexity I end up with, I can always decompose it back into 
basic HTML forms.

Any value can be expressed in .

And semantically, I can always do: role="x-my-custom-role input"

-Charles

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-09-28 Thread Olli Pettay


On 09/28/2011 07:01 PM, Adam Klein wrote:

On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay  wrote:

On 09/24/2011 12:16 AM, Adam Klein wrote:


For each observer, if a registration exists which requests the
matching mutation type and whose observed node set contains the target
node of the mutation, a MutationRecord is appended to the observer's
pending mutation queue. If multiple such registrations exist for a
given observer, a single MutationRecord is delivered having the union
of the information requested by all registrations (e.g.
attributeOldValue).



This is actually still ambiguous.
What if attributeOldValue is first set to true for document.documentElement,
and then false (implicitly or explicitly)
for document, should attribute values be reported?

Another problematic case is that if we have subtree A and B and both
are being observed by same observer but different options. Then some
node from A is moved to B. Which options should be used?

So, should we define that "union" means that 'true' values override
'false' values, and attributeFilter values are union'ed the usual way?


Yes, I think this is what I actually had in mind: true values override
false values.



Actually attributeFilter is union'ed the usual way only if it is defined 
always (in all the options). If it is missing, all the

attributes should be observed.





To make API somewhat more consistent, should we change
"Subsequent calls to the same MutationObserver made with the same |target|
have the effect of resetting the options associated with the registration. "
to follow the union-ing.


If we're going to do that, I think we need to add the ability to stop
listening to a single target (rather than disconnecting from all).
But I'm not convinced we need this consistency, as I suspect the above
case (covering multiple nodes with different registrations and
different options) is quite unusual.


OK, let's keep the re-observe a target the way it is.

-Olli



- Adam

Re: HTML element content models vs. components

2011-09-28 Thread Charles Pritchard

On 9/27/2011 11:39 PM, Roland Steiner wrote:
Expanding on the general web component discussion, one area that
hasn't been touched on AFAIK is how components fit within the content
model of HTML elements.
Take for example a list
(http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-ul-element):

and have "Zero or more elements" as content model,
while is specified to only be usable within , and .

Now it is not inconceivable that someone would like to create a
component that acts as a list item, but expands on it. In order
to allow this, the content model for , , would need to
be changed to accomodate this. I can see this happening in a few ways:

A.) allow elements derived from a certain element to always take their
place within element content models.

In this case, only components whose host element is derived from
would be allowed within , , , whether or not it is
rendered (q.v. the "Should the shadow host element be rendered?"
thread on this ML).

B.) allow all components within all elements.

While quite broad, this may be necessary in case the host element
isn't rendered and perhaps derivation isn't used. Presumably the
shadow DOM in this case contains one - or even several - elements
as topmost elements in the tree.

C.) Just don't allow components to be used in places that have a
special content model.

Thoughts?

Consider the CSS content model: we can easily override the model of
various tags.
Then consider ARIA role types, where we can easily override the
semantics of various tags.

I'm a big fan of using appropriate tag names, but I'm not convinced that
HTML should restrict CSS or ARIA.
The HTML5 editor has repeatedly tried to enforce option C, restricting
components in the DOM tree in relation to ARIA and HTML Canvas.

Why bother over-specifying? Why remove that flexibility?

HTML tag names are fantastic, I'm not saying lets just toss HTML, but I
don't think HTML is the top of the hierarchy.

We have ARIA for semantics, CSS for display and DOM for serialization.

-Charles

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-09-28 Thread Adam Klein

On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay  wrote:
> On 09/24/2011 12:16 AM, Adam Klein wrote:
>>
>> For each observer, if a registration exists which requests the
>> matching mutation type and whose observed node set contains the target
>> node of the mutation, a MutationRecord is appended to the observer's
>> pending mutation queue. If multiple such registrations exist for a
>> given observer, a single MutationRecord is delivered having the union
>> of the information requested by all registrations (e.g.
>> attributeOldValue).
>
>
> This is actually still ambiguous.
> What if attributeOldValue is first set to true for document.documentElement,
> and then false (implicitly or explicitly)
> for document, should attribute values be reported?
>
> Another problematic case is that if we have subtree A and B and both
> are being observed by same observer but different options. Then some
> node from A is moved to B. Which options should be used?
>
> So, should we define that "union" means that 'true' values override
> 'false' values, and attributeFilter values are union'ed the usual way?

Yes, I think this is what I actually had in mind: true values override
false values.

> To make API somewhat more consistent, should we change
> "Subsequent calls to the same MutationObserver made with the same |target|
> have the effect of resetting the options associated with the registration. "
> to follow the union-ing.

If we're going to do that, I think we need to add the ability to stop
listening to a single target (rather than disconnecting from all).
But I'm not convinced we need this consistency, as I suspect the above
case (covering multiple nodes with different registrations and
different options) is quite unusual.

- Adam

[Bug 14296] sorry, does this work

2011-09-28 Thread bugzilla

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14296

Tab Atkins Jr.  changed:

   What|Removed |Added

 CC||jackalm...@gmail.com
 Resolution|NEEDSINFO   |INVALID

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[workers] Back to LC? [Was: RfC: LCWD of Web Workers; deadline September 27]

2011-09-28 Thread Arthur Barstow

The comment period for Web Worker's September 1 LCWD ended yesterday. 
This spec now has 5 open bugs [1].


Additionally, on September 10 the ED was updated to use constructors 
instead of  init*Events methods [2].


Is the expectation: back to LC when the bugs are closed?

-AB

[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Web%20Workers%20%28editor%3A%20Ian%20Hickson%29&resolution=---
[2] 
http://dev.w3.org/cvsweb/html5/workers/Overview.html.diff?r1=1.306;r2=1.307;f=h


 Original Message 
Subject:RfC: LCWD of Web Workers; deadline September 27
Resent-Date:Tue, 6 Sep 2011 14:21:11 +
Resent-From:
Date:   Tue, 6 Sep 2011 10:20:49 -0400
From:   ext Arthur Barstow 
To: public-webapps 



A new LCWD of Web Workers was published:

  http://www.w3.org/TR/2011/WD-workers-20110901/

Please send all comments to public-webapps@w3.org by September 27.

[webstorage] Back to LC? [Was] RfC: LCWD of Web Storage; deadline September 27

2011-09-28 Thread Arthur Barstow

The comment period for WebStorage's September 1 LCWD ended yesterday. I 
didn't notice any e-mail threads specific to this LC but there are 3 
opens bugs at the moment [1].


Additionally, on September 10 the ED was updated to replace 
initStorageEvent with the dictionary-based approach [2].


What is the implementation status of the [2] change (I assume this 
change means another LC is required)?


-AB

[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Web%20Storage%20%28editor%3A%20Ian%20Hickson%29&resolution=---
[2] 
http://dev.w3.org/cvsweb/html5/webstorage/Overview.html.diff?r1=1.181;r2=1.182;f=h


On 9/6/11 10:19 AM, ext Arthur Barstow wrote:

A new LCWD of Web Storage was published:

  http://www.w3.org/TR/2011/WD-webstorage-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Re: [XHR2] Avoiding charset dependencies on user settings

2011-09-28 Thread Henri Sivonen

On Wed, Sep 28, 2011 at 4:16 AM, Jonas Sicking  wrote:
> So it sounds like your argument is that we should do  prescan
> because we can do it without breaking any new ground. Not because it's
> better or was inherently safer before webkit tried it out.

The outcome I am suggesting is that character encoding determination
for text/html in XHR should be:
 1) HTTP charset
 2) BOM
 3)  prescan
 4) UTF-8

My rationale is:
 * Restarting the parser sucks. Full heuristic detection and
non-prescan  require restarting.
 * Supporting HTTP charset, BOM and  prescan means supporting
all the cases where the author is declaring the encoding in a
conforming way.
 * Supporting  prescan even for responseText is safe to the
extent content is not already broken in WebKit.
 * Not doing even heuristic detection on the first 1024 bytes allows
us to avoid one of the unpredictability and
non-interoperability-inducing legacy flaws that encumber HTML when
loading it into a browsing context.
 * Using a clamped last resort encoding instead of a user setting or
locale-dependent encoding allows us to avoid one of the
unpredictability and non-interoperability-inducing legacy flaws that
encumber HTML when loading it into a browsing context.
 * Using UTF-8 as opposed to Windows-1252 or a user setting or
locale-dependent encoding as the last resort encoding allows the same
encoding to be used in the responseXML and responseText cases without
breaking existing responseText usage that expects UTF-8 (UTF-8 is the
responseText default in Gecko).

What outcome do you suggest and why? It seems you aren't suggesting
doing stuff that involves a parser restart? Are you just arguing
against UTF-8 as the last resort?

> And in any case, it's easy to figure out where the
> data was loaded from after the fact, so debugging doesn't seem any
> harder.

If that counts as "not harder", I concede this point.

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

Re: HTML element content models vs. components