On Wed, 28 Sep 2011 03:16:46 +0200, Jonas Sicking jo...@sicking.cc wrote:
So it sounds like your argument is that we should do meta 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
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
):
ol and ul
On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner
rolandstei...@chromium.org 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.w3.org/Bugs/Public/show_bug.cgi?id=14323
Summary: This API could easily be used by XForms
implementations if protocols such as localstorage://
could also be specified. Thanks! Alain Couthures
agenceXML Invited
On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner
rolandstei...@chromium.orgwrote:
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 (
On Wed, 28 Sep 2011, 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 (
On Wed, Sep 28, 2011 at 4:16 AM, Jonas Sicking jo...@sicking.cc wrote:
So it sounds like your argument is that we should do meta 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
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].
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/show_bug.cgi?id=14296
Tab Atkins Jr. jackalm...@gmail.com changed:
What|Removed |Added
CC|
On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay olli.pet...@helsinki.fi 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
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
On 09/28/2011 07:01 PM, Adam Klein wrote:
On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettayolli.pet...@helsinki.fi 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
On 9/27/2011 10:26 PM, Roland Steiner wrote:
On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
[...]
We have an opportunity now to document the sub-elements of single
form controls.
That is certainly a very valid goal. For
The way to solve this is not to change the content models, it's to use an
actual li 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,
On Tue, Sep 27, 2011 at 11:53 PM, Dominic Cooney domin...@chromium.org wrote:
On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner
rolandstei...@chromium.org wrote:
Expanding on the general web component discussion, one area that hasn't been
touched on AFAIK is how components fit within the
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
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.
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
On Wed, Sep 28, 2011 at 11:19 AM, Boris Zbarsky bzbar...@mit.edu 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
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 table and to do that I
have to write:
x-my-table
trtdContent/td/tr
x-my-table
and somewhere before that point register that
On Wed, Sep 28, 2011 at 11:24 AM, Boris Zbarsky bzbar...@mit.edu 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
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
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
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 exampleobject's API
can change dynamcially as it loads new plugins
This is
On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson i...@hixie.ch 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
transitive APIs.
Blergh! TRANSIENT, not transitive.
:DG
On Tue, Sep 27, 2011 at 11:10 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 28 Sep 2011 03:16:46 +0200, Jonas Sicking jo...@sicking.cc wrote:
So it sounds like your argument is that we should do meta prescan
because we can do it without breaking any new ground. Not because it's
better
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
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.
On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio
isra...@microsoft.com
wrote:
On
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch 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
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
exampleobject's API can
On 8/31/11 3:45 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan
a...@mozilla.com 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,
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
I think new elements are completely fine as long as they are
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
I think new
On Wed, Sep 28, 2011 at 2:54 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, Sep 28, 2011 at 4:16 AM, Jonas Sicking jo...@sicking.cc wrote:
So it sounds like your argument is that we should do meta prescan
because we can do it without breaking any new ground. Not because it's
better or was
On Wed, Sep 28, 2011 at 3:55 PM, Israel Hilerio isra...@microsoft.com wrote:
On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
On Mon, Sep
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
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
Hixie wrote:
snip
… 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
I would, again, like to bring up the issue of non-constructable
constructors as the default in WebIDL. It is onerous to down-stream
authors to leave such a foot-gun in the spec if they're *expected* to
provide constructors for most classes (and this is JS we're talking
about, so they are) and it
42 matches
Mail list logo
