Re: Call for Editor: URL spec

On Mon, Nov 5, 2012 at 2:31 PM, Adam Barth wrote: > Is there some reason Anne isn't going to edit the spec? Anne isn't doing the work in WebApps, because he no longer works for a member company, and the Invited Expert agreement is more restrictive in ways that are important to him (it doesn't all

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 1, 2012 at 2:43 PM, Maciej Stachowiak wrote: > On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. wrote: >> On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak wrote: >>> On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov wrote: >>>> Hi folks! >>>> >

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak wrote: > On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov wrote: >> Hi folks! >> >> While you are all having good TPAC fun, I thought I would bring this >> bug to your attention: >> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562 >> >> There's

Re: HTML 5 should include a way to create custom page header & footer for printing.

On Sun, Oct 14, 2012 at 12:10 AM, Mircea LUTIC wrote: > HTML 5 should include a way to create custom page header & footer for > printing. > These should allow to include images > > I think it should be something like > > > My company softwareThe best software on > the planet > > > ... This

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Fri, Oct 5, 2012 at 4:22 AM, Henri Sivonen wrote: > On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr. wrote: >> Similarly, some of the a11y folks have recently been talking about >> applying aria-* attributes via CSS, again, because it's just so much >> more convenient

Re: sandbox

On Sat, Sep 15, 2012 at 5:01 AM, Angelo Borsotti wrote: > Hello, > > restricting the access made by a web app to a sandboxed filesystem is a > severe restriction. > I understand that this is done to preserve security, but the result falls > short of the mark. [snip] > So, my proposal is to get rid

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Wed, Aug 22, 2012 at 6:32 PM, Maciej Stachowiak wrote: > On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. wrote: >> On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell wrote: >>> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. >>> wrote: >>>> Correct. If we

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Wed, Aug 22, 2012 at 9:20 AM, Bronislav Klučka wrote: > On 22.8.2012 1:13, Tab Atkins Jr. wrote: >> Actually, the two should be identical, because CAS is applied as a >> mutation observer, rather than synchronously. As long as those >> statements appear in the same microt

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Wed, Aug 22, 2012 at 9:11 AM, Dimitri Glazkov wrote: > Yes, but... One of the problems with the "is" attribute is that it's > magic: only the parser reacts to it, and changing it does not do > anything. I was hoping for some special notation that clearly made it > not an attribute, so that at l

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov wrote: > Can we extend this to custom DOM element registration somehow? > > ul.news>li { > identity: x-news-item; > } > > or maybe even: > > ul.news>li { > identity: url(//example.com/test/news.html#news-item); > } If that's an attribute o

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard wrote: > FWIW, while I don't find the idea of attaching event listeners this way too > interesting (maybe I could be convinced, but event capturing is already > convenient for most of these examples), being able to say "#myform input { > autocomplete:

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:54 PM, Brian Kardell wrote: > On Aug 21, 2012 6:49 PM, "Tab Atkins Jr." wrote: >> On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell wrote: >>> In other >>> words, >>> what is preventing you from writing... >>> &

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:52 PM, Rick Waldron wrote: > On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. > wrote: >> On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron >> > 3. Where did "evt" come from? >> >> Isn't that one of the magically-defined vari

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou wrote: > I *love* this idea!! > However, I’m afraid that in all these cases, ”it’s so much more convenient” > precisely due to the dynamic nature of CSS, so you don’t have to bind event > handlers to cater to document changes etc. I think this proposal

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell wrote: > On Aug 21, 2012 6:18 PM, "Tab Atkins Jr." wrote: >> So, in my current proposal, you can just set an onfoo attribute: >> >> ul.special > li { >> onclick: "alert('You c

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron wrote: > On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. > wrote: >> ul.special > li { >> onclick: "alert('You clicked me!'); >> evt.target.classlist.add('clicked');"; >> } > > &

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell wrote: > On Aug 21, 2012 5:40 PM, "Tab Atkins Jr." wrote: >> On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai wrote: >>> On a somewhat unrelated note, could we somehow also incorporate jquery >>> style >>>

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai wrote: > On a somewhat unrelated note, could we somehow also incorporate jquery style > live event handlers here? See previous www-dom discussion about this: . I > suppose we'd still just want listen/unlisten(selector, handler) methods, but > they'd get

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 2:20 PM, Travis Leithead wrote: >> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] >> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai wrote: >> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. >> > wrote: >> >> On Tue, Aug

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell wrote: > On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. wrote: >> Correct. If we applied CAS on attribute changes, we'd have... problems. > > Because you could do something like: > > .foo[x=123]{ x: 234

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai wrote: > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. > wrote: >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai wrote: >> > Meh. I think this loses most of the "CSS is so much more convenient" >> > benefits.

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell wrote: > On Aug 21, 2012 4:03 PM, "Tab Atkins Jr." wrote: >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai wrote: >>> Meh. I think this loses most of the "CSS is so much more convenient" >>> benefi

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai wrote: > Meh. I think this loses most of the "CSS is so much more convenient" > benefits. It's mainly the fact that you don't have to worry about whether > the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving

Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

I recently participated in an internal thread at Google where it was proposed to move a (webkit-specific) feature from an attribute to a CSS property, because applying it via a property is *much* more convenient. Similarly, some of the a11y folks have recently been talking about applying aria-* at

Re: Acceptable for CSS to add a "window.CSS" global?

On Sun, Aug 19, 2012 at 3:59 AM, Chaals McCathieNevile wrote: > On Sun, 19 Aug 2012 03:03:19 +0200, Cameron McCormack wrote: >> Chaals McCathieNevile: >>> Frankly, I am deeply sceptical that the CSS group has managed to solve >>> the social problem sufficiently well to make the technical solution

Re: Acceptable for CSS to add a "window.CSS" global?

On Sat, Aug 18, 2012 at 6:03 PM, Cameron McCormack wrote: > Chaals McCathieNevile: >> Frankly, I am deeply sceptical that the CSS group has managed to solve >> the social problem sufficiently well to make the technical solution >> noticeably different from hasFeature. > > I think the biggest diffe

Re: Acceptable for CSS to add a "window.CSS" global?

On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson wrote: > On Mon, 13 Aug 2012, Tab Atkins Jr. wrote: >> The CSSWG would like to add a new top-level object called "CSS" that we >> can hang several functions and constructors off of, so that we can avoid >> the exce

Acceptable for CSS to add a "window.CSS" global?

The CSSWG would like to add a new top-level object called "CSS" that we can hang several functions and constructors off of, so that we can avoid the excessive verbosity that's probably required if we just put everything on window. (Right now, the only thing we want to add is a "supports()" functio

Re: Web Components Suggestion

On Sun, Aug 12, 2012 at 3:36 AM, Florian Bösch wrote: > It's my understanding that if you want to define a strict parser using a DTD > that describes the markup, it's impossible to introduce arbitrary tage names > (as in there are not tag wildcards in a DTD). A document that used arbitrary > tags

Re: [IndexedDB] Problems unprefixing IndexedDB

On Wed, Aug 8, 2012 at 5:06 PM, Kyle Huey wrote: > Hello all, > > Jonas mentioned earlier on this list that we unprefixed IndexedDB in Firefox > nightlies some time ago. We ran into a bit of a problem.[0] Most of the > IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell authors to >

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

s about EOF fixing. See > [1] for other testcases. > > [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0524 > > (12/08/07 0:20), Tab Atkins Jr. wrote: >> Officially, 2.1 defines Kenny's example of "html /*" as tokenizing >> into IDENT

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

On Mon, Aug 6, 2012 at 4:25 AM, Lachlan Hunt wrote: > On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: >> I think this is a very minor issue, and it has a simple workaround - >> mark it as undefined. However, if Lachlan doesn't feel like paying extra >> fee for versionning (what Anne calls "make wo

Re: Why the restriction on unauthenticated GET in CORS?

On Fri, Jul 20, 2012 at 11:58 AM, Henry Story wrote: > Of course, but you seem to want to support hidden legacy systems, that is > systems none of us know about or can see. It is still a worth while inquiry > to find out how many systems there are for which this is a problem, if any. > That is:

Re: [Server-Sent Events] Network connection clarification

On Tue, Jul 10, 2012 at 2:27 PM, Kornel Lesiński wrote: > On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson wrote: >> The idea is to let the script handle network troubles, so that authors are >> in full control of how much load their servers get when they are having >> trouble. The alternative is

Re: [UndoManager] Re-introduce DOMTransaction interface?

On Mon, Jul 9, 2012 at 9:41 AM, Ryosuke Niwa wrote: > On Mon, Jul 9, 2012 at 7:30 AM, Tab Atkins Jr. wrote: >> On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa wrote: >> > Okay, it appears to be a miscommunication of terminology here. What I >> > meant >> > is

Re: [UndoManager] Re-introduce DOMTransaction interface?

On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa wrote: > On Fri, Jul 6, 2012 at 1:46 AM, James Graham wrote: >> On 07/06/2012 02:01 AM, Ryosuke Niwa wrote: >>> On Thu, Jul 5, 2012 at 4:27 PM, Ojan Vafai wrote: In your version, you need to remember the order of the arguments, which requir

Re: Feedback on Quota Management API

On Wed, Jun 27, 2012 at 8:44 AM, Tobie Langel wrote: > On Jun 27, 2012, at 6:44 AM, "Glenn Maynard" wrote: >> Unrelated, screaming-caps on RFC2119 terms (eg. "MUST") is jarring and >> unnecessary.  I'd suggest dropping the em.rfc2119 style.  That's what HTML, >> DOM4, etc. do, and it's much mor

Re: [webcomponents] HTML Parsing and the element

(Please bottompost! Being a Googler teaches you bad email habits. ^_^) On Tue, Jun 26, 2012 at 1:34 PM, Elliott Sprehn wrote: > On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. > wrote: >> On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn wrote: >> > Silly question bu

Re: [webcomponents] HTML Parsing and the element

On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn wrote: > Silly question but why not specify the template element as if it's contents > were PCDATA, and the document fragment is the "value". Then this whole thing > isn't really any different than a . Because you can't nest inside of itself, but w

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

On Thu, Jun 21, 2012 at 3:14 PM, fantasai wrote: > Also, to be precise, you're not actually clear about what happens to e.g. > 'color', which is an inheritable property. If it doesn't inherit from > anything, what is it's value? This is not defined, because currently in > CSS every element has a p

Re: [selectors-api] Consider backporting find() behavior to querySelector()

On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters wrote: > On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu > wrote: >> (12/06/18 22:45), Simon Pieters wrote: >>> >>> I think we should instead either fix the old API (if it turns out to not >>> Break the Web) or live with past mistake (if it

Re: [webcomponents] HTML Parsing and the element

On Thu, Jun 7, 2012 at 2:45 AM, Henri Sivonen wrote: > On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. wrote: >> A call like "document.querySelectorAll('p')" doesn't *want* to get the >> inside the template. > > I think it's backwards to assu

Re: [Process] Publishing use cases and requirements as official docs

On Wed, Jun 6, 2012 at 1:15 PM, Tobie Langel wrote: > OK, but the process is lighter, no? Yes, there is no process besides "the WG agrees to publish it". ~TJ

Re: [webcomponents] HTML Parsing and the element

On Wed, Jun 6, 2012 at 3:50 AM, Henri Sivonen wrote: > On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson wrote: >> On Wed, 4 Apr 2012, Rafael Weinstein wrote: >>> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov >>> wrote: >>> > >>> > Perhaps lost among other updates was the fact that I've gotten the

Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen wrote: > On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking wrote: >>> I think the SVG working group should learn to stand by its past >>> mistakes. Not standing by them in the sense of thinking the past >>> mistakes are great but in the sense of not caus

Re: [webcomponents] HTML Parsing and the element

On Mon, Jun 4, 2012 at 2:42 PM, Ian Hickson wrote: > On Wed, 4 Apr 2012, Rafael Weinstein wrote: >> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov >> wrote: >> > >> > Perhaps lost among other updates was the fact that I've gotten the >> > first draft of HTML Templates spec out: >> > >> > http:/

Re: CfC: publish FPWD of Fullscreen spec; deadline May 24

On Fri, Jun 1, 2012 at 2:02 AM, Anne van Kesteren wrote: > On Wed, May 30, 2012 at 5:47 PM, fantasai > wrote: >>  | If its specified 'position' is 'static', it computes to 'absolute'. > > What if position is not specified? All elements have specified values for all properties. (This happens wh

Re: [admin] Mail List Policy, Usage, Etiquette, etc. & Top-posting

On Tue, May 29, 2012 at 9:28 AM, Jean-Claude Dufourd wrote: > On 29/5/12 17:56 , Julian Reschke wrote: >> >> On 2012-05-29 16:53, Glenn Maynard wrote: >>> >>> On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow >> > wrote: >>> >>>      * Messages should be encoded usingpl

Re: Shrinking existing libraries as a goal

On Thu, May 17, 2012 at 9:56 AM, John J Barton wrote: > On Thu, May 17, 2012 at 9:29 AM, Rick Waldron wrote: >> Consider the cowpath metaphor - web developers have made highways out of >> sticks, grass and mud - what we need is someone to pour the concrete. > > I'm confused. Is the goal shorter l

Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

On Tue, May 15, 2012 at 12:46 PM, Henri Sivonen wrote: > On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein wrote: >> Issue 1: How to handle tokens which precede the first start tag >> >> Options: >> a) Queue them, and then later run them through tree construction once >> the implied context elem

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 11:59 AM, Ryosuke Niwa wrote: > On Fri, May 11, 2012 at 1:55 AM, Henri Sivonen wrote: >> I still think that having to create a DocumentFragment first and then >> set innerHTML on it is inconvenient and we should have a method on >> document that takes a string to parse and

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

the answer is anything other than "Don't even think about it." > On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. wrote: >> The innerHTML API is convenient.  It lets you set the entire >> descendant tree of an element, creating elements and giving them >> attrib

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 2:03 AM, Ian Hickson wrote: > On Fri, 11 May 2012, Tab Atkins Jr. wrote: >> For something like this: >> >> $("Example "+exnum+":").appendTo(container); > > Can we really not come up with anything better? It makes me really sa

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 1:19 AM, Ian Hickson wrote: > On Thu, 10 May 2012, Rafael Weinstein wrote: >> On Thu, May 10, 2012 at 4:01 PM, Ian Hickson wrote: >> > On Fri, 11 May 2012, Tab Atkins Jr. wrote: >> > >> > But ok, let's assume that the use case is &

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 12:50 AM, Ian Hickson wrote: > On Thu, 10 May 2012, Jonas Sicking wrote: >> The jQuery API shows that at least jQuery developers don't agree with >> you regarding what is simpler here. > > That wouldn't be the first time. :-) > > jQuery doesn't really match the Web platform

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 1:01 AM, Ian Hickson wrote: > On Fri, 11 May 2012, Tab Atkins Jr. wrote: >> while Element.create() is great, it solves a different use-case.  Being >> able to construct DOM from raw HTML is easy to read and write and >> understand, particularly when i

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Fri, May 11, 2012 at 12:18 AM, Ian Hickson wrote: > On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> On Thu, May 10, 2012 at 11:20 PM, Ian Hickson wrote: >> > On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> >> Still, requiring an explicit context declaration *at

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Thu, May 10, 2012 at 11:20 PM, Ian Hickson wrote: > On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> Still, requiring an explicit context declaration *at all* defeats most >> of the purpose of the API.  Again, if we don't auto-detect SVG (so that >> "" just par

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 9:13 PM, Anne van Kesteren wrote: > On Wed, May 9, 2012 at 8:14 PM, Yehuda Katz wrote: >> On Wed, May 9, 2012 at 10:24 AM, Jonas Sicking wrote: >>> I think it's much better to prioritize developers over implementers >>> here and let implementers and spec writers tackle the

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 10:32 PM, Scott González wrote: > Perhaps I'm missing something, but isn't "foobar" an > invalid use case? Any top-level element that needs a context can't be mixed > with a text node. Are there cases where this isn't true? Yes - SVG, MathML, and Ruby text can all, in some

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 9:51 PM, Ian Hickson wrote: >> I think the proposals here, and the fact that jQuery has implemented >> context-free HTML parsing, proves that it is technically possible. > > I don't think look-ahead and magically determining the parse mode from a > preparse of the string is

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 5:27 PM, Boris Zbarsky wrote: > On 5/9/12 5:24 AM, Tab Atkins Jr. wrote: >> (Currently, SVG and HTML conflict with

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 11:10 AM, Henri Sivonen wrote: > If we end up doing (flawed) list-based magic, we need to make sure the > SVG working group is on board and henceforth avoids local name > collisions with HTML and MathML. Yes, we (SVGWG) is on board with this. We won't introduce new element

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 10:16 AM, James Graham wrote: > On 05/09/2012 09:52 AM, Henri Sivonen wrote: >> >> On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein >>  wrote: >>> >>> What doesn't appear to be controversial is the parser changes which >>> would allow the template element to have arbitrary

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 9:52 AM, Henri Sivonen wrote: > Why should the programmer first create a document fragment and then > set a property on it? Why not introduce four methods on Document that > return a DocumentFragment: document.parseFragmentHTML (parses like > .innerHTML), document.parseFrage

Re: [webcomponents] Custom Elements Spec

On Tue, May 8, 2012 at 6:17 AM, Anne van Kesteren wrote: > On Tue, May 8, 2012 at 5:48 AM, Dimitri Glazkov wrote: >> ... http://wiki.whatwg.org/wiki/Custom_Tags_Analysis#Accessibility ... >> >> If you look at the two alternatives, one (the "is" attribute) asks the >> authors to make the right cho

Re: Offline Web Applications status

On Fri, May 4, 2012 at 9:09 PM, SULLIVAN, BRYAN L wrote: > I like the idea. This would be useful for various things, especially if we > could integrate the discovery and selection of this feature (the local proxy > Web service) through Web Intents. I don't understand how Web Intents would be us

Re: Offline Web Applications status

On Thu, May 3, 2012 at 11:12 AM, Ian Hickson wrote: > An idea I was kicking around for this would be to simplify the three > points above to instead have just a way to declare a JS file as being a > local interceptor, and then have that JS file be automatically launched in > a worker thread, and t

Re: CfC: to stop work on XBL2; deadline May 8

On Wed, May 2, 2012 at 10:00 AM, Ian Hickson wrote: > On Wed, 2 May 2012, Anne van Kesteren wrote: >> On Tue, 01 May 2012 21:35:45 -0700, Ian Hickson wrote: >> > What happens if it doesn't pass? >> >> I guess we'll reevaluate then. > > How would this be different than what we've been doing for th

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Mon, Apr 30, 2012 at 5:43 PM, Anne van Kesteren wrote: > I personally think it would be better if HTML kept defining all entry points > to the HTML parser. And at least conceptually this is a new insertion mode I > think contrary to what you suggest in > http://lists.w3.org/Archives/Public/publ

Re: [whatwg] [Server-Sent Events] Infinite reconnection clarification

On Fri, Apr 27, 2012 at 4:12 AM, Odin Hørthe Omdal wrote: > I think I should do a TLDR since I didn't really get any answers: > > 1. Should EventSource *ever* time out once it has once been connected? > 2. What do browsers do today? What do you think is a good thing to do? > > I tried Opera, Firef

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters wrote: > On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein > wrote: >> Any other HTML tagName => HTMLBodyElement > > Isn't this one redundant with the last step? No, this captures known HTML tagnames, so that HTML can lay claim on the few tags th

Re: [webcomponents] HTML Parsing and the element

On Thu, Apr 26, 2012 at 9:43 AM, Yuval Sadan wrote: > I totally misread the purpose of templates beforehand -- s act > more like a mixin rather than a fill-in. It also reflects in what Tab wrote > that it's still vague how the two notions - that of text templates and that > of mixins for building

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai wrote: > works for string-based templating. Special handling > of 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 mee

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa 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 doesn't guar

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 25, 2012 at 1:00 PM, Dimitri Glazkov 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 Templates to have

Re: [webcomponents] HTML Parsing and the element

On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell wrote: > On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. wrote: >> On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill wrote: >>> Hmm. I have to say that I disagree that your example below shows a >>> template within a templ

Re: [webcomponents] HTML Parsing and the element

On Tue, Apr 24, 2012 at 9:11 AM, James Graham wrote: > On 04/24/2012 05:57 PM, Yuval Sadan wrote: >> Placing contents as CDATA is an option. I personally think the >> tag as proposed is adhoc to somebody's notion of how templates should work. >> To avoid this I think they should be simpler. I am

Re: [webcomponents] HTML Parsing and the element

On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill wrote: > Hmm. I have to say that I disagree that your example below shows a > template within a template. That is IMO 1 template wherein there is > iteration syntax. The "iteration syntax" is basically an element - the example that Arv gave even used el

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen wrote: > On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov wrote: >> Perhaps lost among other updates was the fact that I've gotten the >> first draft of HTML Templates spec out: >> >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/ind

Re: [webcomponents] HTML Parsing and the element

On Wed, Apr 18, 2012 at 8:46 AM, Anne van Kesteren wrote: > On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen wrote: >> When implementing this, making embedded content inert is probably the >> most time-consuming part and just using a document fragment as a >> wrapper isn't good enough anyway, si

Re: [XHR] XMLHttpRequest.send("")

On Tue, Apr 10, 2012 at 3:58 PM, Glenn Maynard wrote: > On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking wrote: >> Is it more surprising than that >> >> xhr.send(hasSomethingToSend() ? getTheThingToSend() : ""); >> >> sets the Content-Type header even when no body is submitted? > > That's exactly w

Re: [DOM4] Question about collections versus maps

On Tue, Apr 10, 2012 at 1:49 PM, Boris Zbarsky wrote: > On 4/10/12 4:23 PM, Tab Atkins Jr. wrote: >> On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarsky  wrote: >>> On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: >>>> According to current WebIDL spec, an object with a named pr

Re: [DOM4] Question about collections versus maps

On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarsky wrote: > On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: >> >> According to current WebIDL spec, an object with a named property >> getter exposes the list of names as own properties, so you can get >> them with for-in

Re: [DOM4] Question about collections versus maps

On Tue, Apr 10, 2012 at 12:39 PM, Boris Zbarsky wrote: > On 4/10/12 3:35 PM, Alan Stearns wrote: >> What is this group's API preference for a set of objects identified by >> name? > > The real question is what the use cases are, no?  The NamedFlowMap approach > doesn't provide a good way to enumer

Re: informal survey - on spec philosophy

On Mon, Mar 26, 2012 at 3:52 PM, Glenn Adams wrote: > On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. > wrote: >> On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams wrote: >>> "if it isn't written in the spec, it isn't allowed by the spec" >> >&

Re: informal survey - on spec philosophy

On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams wrote: > It has been stated to me that, at least for "open web platform standards", > the following statement is true and is shared by the majority: > > "if it isn't written in the spec, it isn't allowed by the spec" > > I happen to disagree with the tr

Re: CfC: Proposal to add web packaging / asset compression

On Tue, Feb 14, 2012 at 1:24 AM, Paul Bakaus wrote: > Hi everybody, > > This is a proposal to add a packaging format transparent to browsers to the > charter. At Zynga, we have identified this as one of our most pressuring > issues. Developers want to be able to send a collection of assets to the

Re: April face-to-face meetings for HTML and WebApps

I'm definitely interested in attending some f2f webapps meetings. I have no real preference on location. ~TJ

Re: Templates 2: The Real World

On Thu, Feb 9, 2012 at 6:56 AM, Rick Waldron wrote: > Hey everyone, > > I've been following the "HTML Parsing and the element" > thread/conversation since it began yesterday and it's very interesting, but > one thing keeps coming to mind - has anyone working on spent any > significant time using

Re: [xhr] responseType for sync requests in window context

2012/1/26 Mark Callow : > I do not think you should be in the business of brute-forcing authors into > converting their applications to use async XHRs. As far as I understand it, > it is the application's UI that may be unresponsive during a sync XHR. In > that case it should be the app. authors ch

Re: [File API] Draft for Review

On Fri, Jan 27, 2012 at 5:59 AM, Glenn Maynard wrote: > On Thu, Jan 26, 2012 at 11:09 PM, Mike Taylor wrote: >> >> Yes, synthetic keypress have multiple problems--which is why we all use >> libraries to not have to author them by hand. >> >> Regardless, this doesn't change the fact that >> window

Re: [File API] Draft for Review

On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard wrote: > On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. > wrote: >> As I argued in >> <http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html>, >> we should absolutely *not* be adding more boolea

Re: [File API] Draft for Review

On Thu, Jan 26, 2012 at 1:21 PM, Arun Ranganathan wrote: > 2. URL.createObjectURL now takes an optional boolean, following discussions > on the listserv [oneTimeOnly]. As I argued in , we should absolutely *not* be adding

Re: Obsolescence notices on old specifications, again

On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams wrote: > I work in an industry where devices are certified against final > specifications, some of which are mandated by laws and regulations. The > current DOM-2 specs are still relevant with respect to these certification > processes and regulations.

Re: Obsolescence notices on old specifications, again

On Mon, Jan 23, 2012 at 1:01 AM, Ms2ger wrote: > Hi all, > > The recent message to www-dom about DOM2HTML [1] made me realize that we > still haven't added warnings to obsolete DOM specifications to hopefully > avoid that people use them as a reference. > > I propose that we add a pointer to the c

Re: String to ArrayBuffer

On Thu, Jan 12, 2012 at 9:54 AM, Charles Pritchard wrote: > I don't see it being a particularly bad thing if vendors expose more > translation encodings. I've only come across one project that would use > them. Binary and utf8 handle everything else I've come across, and I can use > them to build

Re: String to ArrayBuffer

On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams wrote: > On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen wrote: >> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell wrote: >> > The StringEncoding proposal is the best path forward because it >> > provides correct behavior in all cases. >> >> Do you me

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

On Thu, Jan 12, 2012 at 8:41 AM, Aryeh Gregor wrote: > On Wed, Jan 11, 2012 at 3:09 PM, Charles Pritchard wrote: >> The reason is listed in WCAG2 section 2.1.2 and CR5. >> http://www.w3.org/TR/WCAG/ >> >> The items suggest that a standard means of moving focus be maintained. Users >> should be gi

Re: [XHR] responseType "json"

On Fri, Jan 6, 2012 at 12:36 PM, Ojan Vafai wrote: > I'm ambivalent about whether we should restrict to utf8 or not. On the one > hand, having everyone on utf8 would greatly simplify the web. On the other > hand, I can imagine this hurting download size for japanese/chinese websites > (i.e. they'd

<    1   2   3   4   5   >