Re: URL comparison
I'd like to add to what Brian is saying below: This is effectively the goal of the public-nextweb group as I see it. We want to provide a way for developers to build these types of prollyfills and .. More importantly .. Share and publicize them to get the necessary exposure and feedback. Without that second part there is no point in the first. I think prollyfill.org could be more useful if it acted as a registry for these things. In fact Brian and I did this with Hitch (leveraging Github as the source host) and I tend to believe this is the right way. Right now there is a wiki listing the known prollyfills out in the wild but maybe this is not easy to find and not easy to provide feedback too. It's my opinion that prollyfill.org turn into a registry that is simply pointer to Github projects. Thoughts? On 5/1/13 10:03 AM, Brian Kardell bkard...@gmail.com wrote: + the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: We created a prollyfill for this about a year ago (called :-link-local instead of :local-link for forward compatibility): http://hitchjs.wordpress.com/2012/05/18/content-based-css-link/ Cool! If you can specify the workings, we (public-nextweb community group) can rev the prollyfill, help create tests, collect feedback, etc so that when it comes time for implementation and rec there are few surprises. Did you get any feedback thus far about desired functionality, problems that are difficult to overcome, ..? -- http://annevankesteren.nl/ We have not uncovered much on this one other than that the few people who commented were confused by what it meant - but we didn't really make a huge effort to push it out there... By comparison to some others it isn't a very 'exciting' fill (our :has() for example had lots of comment as did our mathematical attribute selectors) - but we definitely can. I'd like to open it up to these groups where/how you think might be an effective means of collecting necessary data - should we ask people to contribute comments to the list? set up a git project where people can pull/create issues, register tests/track fork suggestions, etc? Most of our stuff for collecting information has been admittedly all over the place (twitter, HN, reddit, blog comments, etc), but this predates the nextweb group and larger coordination, so I'm *very happy* if we can begin to change that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shrinking existing libraries as a goal
A few questions: 1. What is the definition of a modern browser that we could build data against? 2. Is this a line-in-the-sand kind of effort? (meaning libraries become smaller but limited in browser compatibilities). On May 15, 2012, at 9:46 PM, Yehuda Katz wrote: Yehuda Katz (ph) 718.877.1325 On Wed, May 16, 2012 at 12:43 AM, Brian LeRoux b...@brian.io wrote: +1 We've been saying this for a long time on the PhoneGap team. Indeed, it is happening, as evidenced by libs like xuijs and zepto, but having a stated goal and formal process to monitor and respond to community hacks, shims, libs, and practices would be great. Awesome. For what it's worth, the shortcuts taken by Zepto et al make it hard for jQuery and other libraries to actually become smaller. They give off the impression that the browsers are getting better, but performance footguns and small problems in new APIs often put the kibosh on actually using the new features. In most cases, these small issues make it nearly impossible to simply replace an area of jQuery code with a new feature and remove the old code. Sometimes the old code is still needed for some code paths, even if it is no longer needed for all code paths. On Wed, May 16, 2012 at 6:32 AM, Yehuda Katz wyc...@gmail.com wrote: In the past year or so, I've participated in a number of threads that were implicitly about adding features to browsers that would shrink the size of existing libraries. Inevitably, those discussions end up litigating whether making it easier for jQuery (or some other library) to do the task is a good idea in the first place. While those discussions are extremely useful, I feel it would be useful for a group to focus on proposals that would shrink the size of existing libraries with the implicit assumption that it was a good idea. From some basic experimentation I've personally done with the jQuery codebase, I feel that such a group could rather quickly identify enough areas to make a much smaller version of jQuery that ran on modern browsers plausible. I also think that having data to support or refute that assertion would be useful, as it's often made casually in meta-discussions. If there is a strong reason that people feel that a focused effort to identify ways to shrink existing popular libraries in new browsers would be a bad idea, I'd be very interested to hear it. Thanks so much for your consideration, Yehuda Katz jQuery Foundation (ph) 718.877.1325
Re: [webcomponents] HTML Parsing and the template element
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.
But to further my point: Where does the demarcation of template stop and
template syntax begin in your example? Or are you saying that the template
syntax is in fact that demarcation?
On 4/24/12 8:48 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote:
I know of many, many templating systems and I have simply never (aside
from MDV) seen it in exactly this light (that is templates actually
embedded in others), regardless of whether those are for within the
browser for generating HTML (or anything else) or on the server - or
even for code generation. It seems to me that there is a rich history
of templating text, it's very useful and in every case I have seen you
have a template and that template can contain references to other
templates, not embed them... Am I seeing this improperly? This seems
to be the case with freemarker, velocity, mustache, handlbars, even
jsp, asp, php, etc - (there are really a lot of them, I'm just
throwing out a bunch). This kind of approach does not seem like it
would be out of place in HTML or even XML - we think about a lot of
things that way (in terms of references). Are there some in
particular that someone could point to that illustrate otherwise?
Most system do allow it. The syntax they use might not make it clear.
http://emberjs.com/#toc_displaying-a-list-of-items
ul
{{#each people}}
liHello, {{name}}!/li
{{/each}}
/ul
In here there is a template between the start each and end each.
--
erik
Re: [webcomponents] HTML Parsing and the template element
I agree with these statements: there is no use for the contents before it is used programmatically it's never considered to be part of the document's semantic content I'd like to add that the only use-case for a template/ tag (IMO) is to deliver content to the UA safely preventing the DOM from using it. I would never want the UA to present this content or place it in the element stack before something has programmatically manipulated it. To have the UA parse it and add it to the element stack seems problematic in that it would possibly have to be reversed out once I'm done manipulating it. From: Yuval Sadan sadan.yu...@gmail.com Date: Tue, 24 Apr 2012 18:57:46 +0300 To: Rafael Weinstein rafa...@google.com Cc: public-webapps public-webapps@w3.org, Ryosuke Niwa rn...@webkit.org Subject: Re: [webcomponents] HTML Parsing and the template element Resent-From: public-webapps@w3.org Resent-Date: Tue, 24 Apr 2012 15:58:26 + Placing contents as CDATA is an option. I personally think the template/ 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 not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? 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, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as
Re: [webcomponents] HTML Parsing and the template element
Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. This is a great point: What parser? If you're implying the HTML Parser, then I think we're talking about a Templating syntax and not just a template/ tag. To which I would imagine is the hard road to take. On 4/24/12 9:45 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com 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 element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
Re: [webcomponents] HTML Parsing and the template element
I'd like to weigh in on this topic as it is something that I'm involved in at work as well. Could you maybe explain further parsing the template contents as HTML can contain sub templates? If you take this example: template div!-- A little markup //--/div template!-- subtemplate markup //--/template div!-- A little more markup //--/div /template Are you saying there is 1 Node that has a 3 children? If yes what benefit does that bring that inert tags doesn't? On 4/23/12 8:25 PM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? 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, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element
