May 1 is the deadline for comments for the CORS LCWD
http://www.w3.org/TR/2012/WD-cors-20120403/.
Original Message
Subject:TransAnn: CORS published as Last Call Working Draft
Resent-Date:Tue, 3 Apr 2012 17:58:36 +
Resent-From:www-...@w3.org
Date: Tue, 3
Anne, Brad, All - does it appear it would be useful for WebApps and
WebAppSec to schedule some joint meeting time on May 2 re CORS (the LC
deadline is May 1 http://www.w3.org/TR/2012/WD-cors-20120403/)?
Currently, WebApps' agenda for that day is mostly wide open
It does feel very sensible that regardless of templates this is a useful
feature that we've long desired.
On Apr 24, 2012 8:28 AM, Rafael Weinstein rafa...@google.com wrote:
No, I hadn't. Let me digest this thread. Much of what I'm implicitly
asking has already been discussed. I'll repost if I
Right. I just want to make sure we agree on the exact feature set and
behavior before WebKit implements it.
On Wed, Apr 25, 2012 at 7:39 AM, Brian Kardell bkard...@gmail.com wrote:
It does feel very sensible that regardless of templates this is a useful
feature that we've long desired.
On
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web components or declarative MDV-like data binding...
I guess this is mostly a question for Dimitri or Dominic, but:
template is used/referenced extensively in the Web
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web components or declarative MDV-like data
binding...
I guess this is mostly a question
Hi Marcos, All - the comment period for the Widget Update LC ended on
April 19. AFAIK, no comments were submitted.
Is anyone aware of any reason(s) to *not* start a CfC to publish a CR -
based on the LC?
-Thanks, AB
On 4/12/12 8:05 AM, ext Arthur Barstow wrote:
Original Message
On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web
Ok, so from the thread that Yehuda started last year,
There seem to be three issues:
1) Interop (e.g. WRT IE)
2) Defining the behavior for all elements
3) HTML vs SVG vs MathML
I think what Yehuda outlined earlier is basically right, and I have a
proposal which accomplishes everything he wants
On Wed, Apr 25, 2012 at 11:32 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however, that there
That would be a major leap forward in the least right?
On Apr 25, 2012 3:41 PM, Rafael Weinstein rafa...@google.com wrote:
Ok, so from the thread that Yehuda started last year,
There seem to be three issues:
1) Interop (e.g. WRT IE)
2) Defining the behavior for all elements
3) HTML vs SVG
On Wed, Apr 25, 2012 at 12:39 PM, Rafael Weinstein rafa...@google.com wrote:
Ok, so from the thread that Yehuda started last year,
There seem to be three issues:
1) Interop (e.g. WRT IE)
2) Defining the behavior for all elements
3) HTML vs SVG vs MathML
I think what Yehuda outlined
My concern with the proposal is that it currently requires libraries
to still do a regexp and special case frameset and html.
We should imply the correct context for all tags in HTML5, not matter
if we like them or not. I think it is important that any valid HTML
with one top level node works and
I'm in favor of the proposal. It solves all of the cases I know about.
For what it's worth, libraries do not, today, bother dealing with html and
frameset. Here are the regular expressions jQuery uses in its cleaning
process:
On Wed, Apr 25, 2012 at 4:55 PM, Yehuda Katz wyc...@gmail.com wrote:
https://github.com/jquery/jquery/blob/master/src/manipulation.js#L17-42
For posterity:
https://github.com/jquery/jquery/blob/247d824/src/manipulation.js#L17-42
I agree. Changing the context element based on the first element is strange
and counter-intutitive and doesn't buy us anything.
For example, enforcing the in table insertion mode when we encounter td
as the first element doesn't guarantee into where this fragment is
inserted. In fact, it can be
jQuery seems to think it buys us something because we have implemented
exactly that.
Yehuda Katz
(ph) 718.877.1325
On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
I agree. Changing the context element based on the first element is
strange and counter-intutitive and
On Wed, Apr 25, 2012 at 3:05 PM, Yehuda Katz wyc...@gmail.com wrote:
jQuery seems to think it buys us something because we have implemented
exactly that.
Do you know why jQuery does it that way?
- Ryosuke
On Wed, Apr 25, 2012 at 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
No. Also, as spec'd today, HTML Templates
(http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html)
do not have anything like token replacement or iteration.
Though, of course, we'd like to augment
And when that becomes the case, then using the source text becomes
problematic not just less efficient right?
On Apr 25, 2012 6:15 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 25, 2012 at 1:00 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
No. Also, as spec'd today, HTML
On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
I agree. Changing the context element based on the first element is strange
and counter-intutitive and doesn't buy us anything.
For example, enforcing the in table insertion mode when we encounter td as
the first element
script type=text/html works for string-based templating. Special handling
of /script is not a big enough pain to justify adding a template element.
For Web Components and template systems that want to do DOM based
templating (e.g. MDV), the template element can meet that need much better
than a
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling of /script is not a big enough pain to justify adding a template
element.
...
String-based templating already works. We don't need new API for it.
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special handling
of /script is not a big enough pain to justify adding a template element.
For Web Components and template systems that want to do DOM based templating
On Apr 25, 2012 7:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling
of /script is not a big enough pain to justify adding a template
element.
For
On Wed, Apr 25, 2012 at 4:22 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling
of /script is not a big enough pain to justify adding a template
Yes!! Thanks guys...that's exactly the distictions and clarifications I
was looking for...assuming these are acceptable distinctions, definitions
and goals.
On Apr 25, 2012 8:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell bkard...@gmail.com
27 matches
Mail list logo
