Re: Officially deprecating main-thread synchronous XHR?
What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote: Agreed. I think for this to be effective we need to get multiple browser vendors being willing to add such a warning. We would also need to add text to the various versions of the spec (whatwg and w3c). For what it's worth, was done when Olli brought this up in #whatwg: http://xhr.spec.whatwg.org/#sync-warning -- http://annevankesteren.nl/
Re: [testing] Common way to manage test bugs?
(not sure the best way to reply to this list and the infra list) On Thu, Dec 19, 2013 at 9:54 AM, Arthur Barstow art.bars...@nokia.comwrote: * Bugzilla - WebApps has a single Testing component in Bugzilla for all of the specs and it has been used to report a few test case bugs [Bugs]. Using Bugzilla addresses #1, however, a single component makes #2 a bit tricky although that could be addressed by prefixing titles with the spec name (e.g. [workers] ...). We should definitely pick one or the other, but there doesn't seem to be a clear favorite right now based on number of open issues. GitHub has 135 open issues, with 124 PRs, so there are 11 actual issues. Bugzilla has 6 open issues. If Bugzilla is chosen, then GitHub issues should be disabled for the repo. * GitHub PRs - some bugs are noted in comments to a PR (and thus making #2 a bit difficult). If the bug isn't contained inside the PR itself, then this seems like it's just bad behavior. Any existing bugs that are discovered as a result of reviewing a PR should go through the normal bug submission process. Any bugs within the PR should be comments on the PR. * GitHub Issues - some bugs are reported as a Github Issue but GH's Issue granularity is for all of [WPT] and not per spec (thus making #2 a bit tricky, although title prefixing could help). For GitHub, we should use labels instead of title prefixing. An issue can have multiple labels, so that addresses the multi-component issue as well. * The WPT root [WPT] is silent on how to file bugs (although some sub-resource could address that) and that could be appropriate if we expect every test suite to be able to customize its bug reporting policy. We should update README.md and CONTRIBUTING.md to document whatever decision is made. If we agree Bugzilla should be used to report all test case bugs: 1) should we have an agreed way for a test suite in WPT to point to Bugzilla (although Bugzilla has bug reports for websockets and workers tests, that link is missing from the test suites); 2) should we continue to lump all of the tests in a single component or create per test suite components (e.g. tests-workers, workers-tests, ...). Can Bugzilla listen to GitHub events and auto-comment? I think we should definitely have organization by components as we already know this is a pain point in other areas, such as email notifications.
Re: [testing] Common way to manage test bugs?
I've copied the two messages (mine and Domenic's) that went only to public-webapps into the public-test-infra thread. On Thu, Dec 19, 2013 at 11:25 AM, James Graham ja...@hoppipolla.co.ukwrote: On 19/12/13 16:09, Domenic Denicola wrote: I would encourage use of GitHub for greater developer involvement. I think elsewhere in the thread it's been covered how to adapt GitHub issues to solve the potential problems you mention, so hopefully it's sufficient technically for your needs. Just wanted to give a voice to that perspective, if it comes down to a matter of preference. This discussion has forked. Can we have it on public-test-infra, since it's a pretty clear cross-group concern related to testing. (BTW I have also advocated GH there, even though the issue tracker sucks).
Re: Styling form control elements
On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote: If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. And you'll make the experience worse for many users because many users have devices that you actually don't want to replace. Also, all the other problems about validation, semantics, etc.
Re: Styling form control elements
On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote: I did mention that these would probably be turned into reusable components in widget libraries. If they hope to be used by developers I see no reason why the issues you raised would not be addressed by those libraries. Are you aware of libraries addressing these issues today? As mentioned multiple times already, there is nothing to inform a developer what UI/UX will be most effective. This is why the best we can do right now is leave certain devices alone while using custom UIs for other devices. But we don't know (in code) which devices those are.
Re: Styling form control elements
Yeah, the big issues come in with using the existing elements. Given input type=date, we want to keep all of the semantics (the APIs, built-in validation, etc.), but apply custom styling. Custom styling may come in the form of CSS or it may come in the form of a completely new UI that uses JS. The latter may or may not use shadow DOM. But the important thing is that we don't actually want to create a new element type, we want to leverage the existing ones. To complicate this further, we may want to just leave it alone in some devices because the native behavior is already optimized. Unfortunately it's hard to tell when that's the case. On Thu, Dec 5, 2013 at 10:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/5/13 4:30 AM, Ryosuke Niwa wrote: As I understand it, people want to do: select name=cities is=map That's not the main issue being discussed right now, as far as I can tell. What's being discussed, I think, is that people want to do things like: input type=date and then style the datepicker in some particular way. -Boris
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 4:45 PM, François REMY francois.remy@outlook.com wrote: If we add matchesSelector as an official alias to matches the same way querySelector and querySelectorAll will be aliases to query and queryAll soon, it should be possible to drop the prefixed version. This is possible, according to my definition of possible. Sorry about this being off-topic, but since query() keeps coming up as a comparison, I think this is a relevant question: query() and queryAll() are going to be aliases? I thought the new names were being created to fix the mismatch between how web developers think and how querySelector() works, specifically only matching from within the context.
Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM
On Thu, Mar 28, 2013 at 12:49 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney domin...@chromium.orgwrote: On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn espr...@gmail.comwrote: offsetParent is very useful to find your positioned parent, and you're crippling that feature and making authors use distributedParent + getComputedStyle() repeatedly which is considerably more expensive. What are those use cases, except finding the position of an element relative to another element, which I think is not excessively complicated by what I am proposing here? Not complicated, just very expensive. getComputedStyle allocates a new object on every invocation and does string parsing. Unfortunately it seems jQuery already does this: https://github.com/jquery/jquery/blob/master/src/offset.js#L126 I read this last sentence as The most popular JavaScript library doesn't suffer from any problems with this proposal. This is unfortunate. I'm sure you meant that it's unfortunate that we take the slow path, but as Boris has already stated Note that if you're using offsetWith/Height/Top/Left you already lose, because they return integers. We tried to ignore this problem for years. Unfortunately, he's right and using offset* will eventually sneak up and cause seemingly inexplicable bugs. Also, considering that jQuery is already doing this, it seems clear that this isn't a performance bottleneck. FWIW, I was going to make the same exact argument that this proposal was going to break code for positioning elements relative to other elements, which is something we do dynamically all the time in jQuery UI. But then I looked at the code in jQuery core and asked Mike Sherov if he could provide feedback. I think he never did because there just doesn't seem to be a good response. Coincidentally, a few days later, Mike and I were reviewing some completely unrelated code and spent at least half an hour trying to figure out why some elements were being positioned 1px off from their expected location and it came down to offset* being lossy.
Re: window.event and Event.srcElement
On Mon, Mar 25, 2013 at 3:47 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Mar 25, 2013 at 7:19 PM, Dave Methvin dave.meth...@gmail.com wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the first one. Is that a real option? I've never seen anything but old IE code intentionally use window.event, and it seems like the uses on SO could easily be from clueless people doing the copy-pasta on very old code. If you can get it removed from WebKit or even just Chrome, it might be. I've filed an issue to see if there's any chance of getting it removed from Chrome: https://code.google.com/p/chromium/issues/detail?id=223749
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 13, 2013 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: In the non-hidden case, I believe .shadowRoot is how you get access. I meant in the non-hidden case. The name should make sense in terms of accessing this property. exposeRoot, hideRoot, publicRoot? Re-reading Dimitri's email, in his description he kept saying non-traversable, and then goes on to suggest names. Were there objections to traversable/non-traversable? It seems like that was the natural way to describe it during discussion. On a related note, most of the suggestions have a negative context (such that enabling takes something away), as opposed to a positive context (such that disabled takes something away). Is there a proposed API for this? I'm assuming this would be exposed via JS, not HTML, so it would be fine for the API to have a positive context and the developer would set the value to false to turn off the default behavior of exposing the root. I don't have a strong opinion either way, it just stuck out that everyone was using a negative context. If this would be exposed via an HTML attribute, then the negative context makes sense.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
It's been a while since I looked at this spec, what are the ways in which you can get access? It seems like a name such as traversable could work well. On Tue, Mar 12, 2013 at 6:47 PM, Daniel Buchner dan...@mozilla.com wrote: What about obscured, opaque, invisible, or restricted? On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote: On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed. Apologies in advance for adding to the bikeshedding protected (mostly private, but you can get around it) shielded (the shield can be lowered) gated (the gate can be opened) fenced (most fences have an opening) Or bleenish-grue, if we're going with color names. Alan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Fri, Mar 8, 2013 at 12:03 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 7.3.2013 19:54, Scott González wrote: Who is killing anything? Hi, given http://lists.w3.org/Archives/**Public/public-webapps/** 2013JanMar/0676.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0676.html I've misunderstood your point as advocating against Shadow altogether. Ok, good to know that this was mostly just a miscommunication. 2nd is is practical: not having to care about the internals, so I do not break it by accident from outside. If the only way to work with internals is by explicit request for internals and then working with them, but without the ability to breach the barrier accidentally, without the explicit request directly on the shadow host, this concern is satisfied and yes, there will be no clashes except for control naming. My understanding is that you have to explicitly ask to walk into the shadow, so this wouldn't happen accidentally. Can someone please confirm or deny this?
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say exposing internals here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) Not exposing internals by default, with a way to opt into exposing. I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals. And what do you feel the pros are of whichever one you're talking about compared to the items after it on the list, just so we're on the same page? In terms of web components, I'm not sure I (or anyone else on the jQuery team) have too strong of an opinion on the default. However, I can say that I find it extremely annoying that I can't reach into the Shadow DOM for new input types and just kill everything. I want input type=date to render as input type=text because native HTML will likely never be as flexible as custom JS components. Obviously I'd prefer a standard, and web components are supposed to solve this. But in the meantime, we're provided with useful semantics and validation that go unused if you want the flexibility of a JS date picker. As someone building JS components, I see the benefit of having the internals exposed to me so I can do as I please. I also recognize the pain of maintaining code that reaches into internals. As someone who cares about the future of the web, I see the very real danger of this becoming widespread and ending up in the situation Boris wants us to avoid.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 1:37 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Your questions about things like should scripts use closures are just derailing the conversation. I'm honestly not sure it's worth replying to any of your points. But to clarify some points I think are relevant: You are right, because someone is trying to kill important (from my point of view) technology: being able to actually create reusable UI libraries. We're talking about a default value, not what functionality is or isn't available. I don't see who is trying to kill your important technologies. But regardless of how clever people work on it, it's not self contained, it leaks where? in DOM/CSS and it collides. This is the nature of the web. There does not exist technology that prevents this. We're discussing that technology right now. But specifically, we're only discussing the default behavior: Do we default to how the web has always worked or do we break tradition? It's not possible to expose potions of a DOM. So, if you want any customization at the DOM level, it's all or nothing. You can't expect to expose a JS API on top of a web component that is small and nice to work with and provide the flexibility of having control over the DOM. You can document that your web component provides some hierarchical structure and uses classes in a specific way. Then users can make modifications, for example, injecting additional markup, without breaking the structure or semantics of the existing web component. I'm not advocating for total anarchy. But that is exactly my point. I do not want to expose the whole DOM and then make programmer read tons of docs. about internals because they leak. So don't. Opt-in to having your DOM be private. I cannot imagine to have app using 50 different controls/component from 4 vendors and having to figure out how to make them not clash Why are they clashing? Web components are self-contained. The only collisions that would exist are either 2 vendors creating the same custom name or a script that isn't even a web component reaching into a web component. The former is impossible to avoid, the latter is what we're discussing (usefulness of being able to dive into a shadow root. If it's safe to modify DOM, I make it public. If it's not, than it is not, then do not touch it. Again, this is all or nothing. If you want it private, you can do that. Nobody is saying this shouldn't be an option. As for the input type=date example: This isn't arbitrary 3rd party scripts coming and crippling your DOM in unexpected ways. This is you as the developer of the site saying the native experience is too limiting and then opting in to a different UI. This is also not global, change the world behavior, this is on a per-element basis. well... if the 3rd party control is not fitting to your scenario, don't use it, or rewrite it (if you have the permission). Again, you're completely missing the point. I WANT the 3rd party control, but I also want the semantics of input type=date. Today it's one or the other. In the future, web components will allow you to have both (as explained by Dimitri). My JS example may seem like distraction to you, but it's actually the same point here yet again. If you find JS class that is almost there, you have 3 choices: rewrite it, throw it away and find another or write your own. Those options suck. Seriously. By the way, option 1 and option 3 are the same. Yes, you are the developer of the site, so you can choose what you want/can use. It's not mandatory for you to use input[type=date] containing shadow. Pick another, write your own. Again, the web platform is providing functionality which I cannot use then. We need to empower developers to leverage the technology built into browsers. I should probably take the time to dig through the archives and find threads about why making everything a black box sucks for web developers. If it's wrong technology for you, do not use it. But why killing it altogether for anyone? Because someone else wrote something you cannot modify? Who is killing anything?
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 1:12 PM, Rafael Weinstein rafa...@google.com wrote: I'm curious if jQuery or others have experienced feeling restricted because apps are depending on internals by way of having access to them via monkey-patching This is unfortunately a very real pain for jQuery. On the flip side, exposing the internals is hugely beneficial. Boris' concerns are legitimate, but we feel the pros of exposing internals outweigh the cons.
Re: [webcomponents] Making the shadow root an Element
There is also a discussion taking place in the jQuery bug tracker [1] related to issues arising from shadow roots not being elements. [1] http://bugs.jquery.com/ticket/13342 On Mon, Feb 11, 2013 at 6:49 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Right now, the shadow root inside a component isn't an element, so it can't host styles, etc. This makes a few things weird, though. For example, it means that it's non-trivial to get at the style of text nodes directly inside the shadow. Normally you can just look at the parentNode of a text node, but here you have to actually look at the host element. And if the host element has blocked inheritance, you can't even do that - you have to calculate the initial value for yourself, because there's nothing you can actually *ask* for the style information. For another example, it means that you can't do any inheritance-blocking yourself, without inserting an additional wrapper. If you let author inheritance through, but you want to block specific properties, you'd want to set property-in-question: default; at the root of the shadow, so it'll reset to its normal value. Alternately, if we implement inheritance-blocking with CSS's new 'all' property http://dev.w3.org/csswg/css3-cascade/#all-shorthand, we need to set it on some root, but that doesn't yet exist. I propose that we reify the shadow root into an element, but default it to display: contents; http://dev.w3.org/csswg/css-display-3/#the-display-box in the UA stylesheet. That way it has no layout effect by default, but provides a handy element for doing all the things I've talked about in this email. I haven't thought through all the implications so far, though, like what the element name is, if it can have attributes set on it, etc. Thoughts? ~TJ
Re: Trialing Web Components
On Mon, Jul 9, 2012 at 3:09 PM, rektide rekt...@voodoowarez.com wrote: My attempt is at: https://gist.github.com/3078187 I think you meant https://gist.github.com/3078197
Re: Proposal: Document.parse() [AKA: Implied Context Parsing]
On Fri, May 25, 2012 at 3:01 AM, Rafael Weinstein rafa...@google.comwrote: -if start tag is td or td typo: th
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 7:13 AM, Henri Sivonen hsivo...@iki.fi wrote: However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we also add a method on Document that parses a string using the HTML parser regardless of the HTMLness flag of the document and returns a DocumentFragment (or has an optional extra argument for forcing XML parsing explicitly). Just a side note, but at least parsing XML seems to be fairly sane today. I haven't really done any testing around this, but it seems like this would get you parsing of arbitrary XML fragments, including leading and trailing text nodes: (new DOMParser).parseFromString( x + string + /x, text/xml ).documentElement.childNodes Obviously this is overly verbose compared to document.parse( string, flag ).
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Why is simplicity not enough of an answer? If you're developing a widget which uses templates for various portions, then as the widget developer you won't know the context for each template. You could probably figure it out by rendering the templates from top to bottom and inspecting the element where the next template will be inserted, but that's unnecessary work if the browser can do it for us. Alternatively, you can ask the user to provide the context, but then your widget API goes from simple strings to either hashes or arrays. On Thu, May 10, 2012 at 6:18 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch 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 rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. Yes, I understand that. But what's the use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 7:01 PM, Ian Hickson i...@hixie.ch wrote: But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. Do you realize that a very large percentage of developers are already doing this and will continue to do it regardless of whether UAs provide this functionality?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Let's pretend that $() doesn't exist and we exposed this functionality as jQuery.createElementFromHtml(). FWIW, web authors' design aesthetics don't really match the Web platform's design aesthetic. This is why broken APIs like querySelectorAll() will be replaced by intuitive APIs like find(). On Thu, May 10, 2012 at 6:50 PM, Ian Hickson i...@hixie.ch 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's design aesthetic, with method names consisting purely of punctuation, methods that can be used both to register a callback and invoke a callback (click(f) vs click()), the style of using return values to enable chained invocations of methods on a specific object, etc. I have great respect for jQuery as a library, but I'm not sure it's necessarily a given that just because jQuery does something one way, it makes sense for the Web platform to do it that way as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein rafa...@google.comwrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: If we're going to do that, then we don't need any lookahead at all. We should support literally that: parsing one element and its descendants. We determine what element is being generatd by looking at the top of the string (div ... - it's a div, tr ... - it's a tr, etc), and we parse until that element is popped from the stack or the end of the string is reached. This avoids all the problems with doing magical lookahead. This was more or less Yehuda's original proposal. If we can make this work, I think it also solves the problem and would be acceptable. My sense is that this solution probably introduces more complexity into the parser and it's output isn't any superior. Yehuda has actually been complaining about this limitation for quite a while. I know that he would not consider this a full solution.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 8:03 PM, Ian Hickson i...@hixie.ch wrote: I understand that people do this kind of thing all the time, but I've always at least assumed that everyone agreed that it was a necessarily evil because the alternatives were even worse. I had hope when we were discussing Element.create() that maybe we were finally coming up with a workable alternative, but as far as I can tell that never went anywhere and now we're actually talking about adding APIs to _support_ string-based DOM tree generation as if it's an actually sane way of writing code. I'm not sure why this isn't sane. It's exactly how everyone writes their code on the server, where the majority of their markup is generated. Raw HTML with variables is much more human friendly than structured JavaScript objects and arrays. Developers are already in the mindset of writing HTML fragments. They do it everywhere. In a traditional web model, you never run into the context problem because the server always generates a full page. So even if you're using nested templates on the server, with some of your templates being fragments that might require context (say a tr), by the time it reaches the browser it's already concatenated into a full page. As web apps become more advanced and servers start returning fragments (or the fragments are just generated directly on the client), then these issues start to crop up. In the developer's mind, nothing has changed about how to generate the markup. There's little incentive to switch from strings to Element.create(), but there's a lot of incentive to stay with strings.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Users will surely find this annoying when they know that it can be
automated. This will also result in users being tripped up on this as they
learn about this feature by looking at some other code that isn't passing a
context (because it doesn't need one) and then all of a sudden they hit a
case where they need one and it fails.
On Wed, May 9, 2012 at 1:01 PM, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Perhaps I'm missing something, but isn't foocaptionbar/caption 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? I don't know how the actual parsing works, but the following logic seems reasonable to me: If the first character is not then use the default context. Otherwise, read all continuous characters that are valid for element names. If the element name found is valid, then use that to determine the context. Otherwise, use the default context. Parse the string using the context determined above. This should result in every possible string having a deterministic outcome, based on existing rules. On Wed, May 9, 2012 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 May 2012, Jonas Sicking wrote: I think having to provide a context every wherewhere you want to parse HTML is creating very bad developer ergonomics. You wouldn't have to provide it everywhere. The vast majority of the time, the default body context is fine. 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 really a sane solution. It doesn't handle all cases (e.g. it doesn't handle the style example I gave), and it results in very weird results (very bad developer ergonomics) for cases like 1GB of text followed by caption vs 1GB of text followed by coption (where the former loses the text and the latter does not). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Custom Elements Spec
On Tue, May 8, 2012 at 1:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: For the same reason that jQuery plugins are authored by a significantly smaller set of people than jQuery users. Significantly smaller, but not necessarily significantly more capable. *Theoretically*, every jQuery user can write their own plugins - it's really easy, and very useful. In practice, almost everyone uses ones written by someone else. Part of the *point* of Components is to reach exactly this model, and have a safe (from an author-usability perspective) way to include someone else's HTML in your own, so we're not all constantly reinventing the same markup patterns. Staying with the jQuery comparison, there are TONS of plugins that solve the same problem. Some in much better ways than others. There's a large potential for problems when the learning curve for the basics is low. There's an even larger problem when developers start blogging about their recent discovery (which no doubt will lack any form of accessibility) and other developers start learning from there. And it's not exactly about making the right choice. Component authors will have to do a significant amount work. Again, the example of jQuery is instructive. A lot of plugins do *not* create accessible markup. However, the most popular ones *do*, and because of this, you end up with much more accessible markup overall than if every user was inventing things themselves. I'd say some do, and an extremely minuscule amount actually use ARIA. I'm not convinced that even the top 10% of developers writing plugins are always thinking about accessibility. Accessibility is hard. I can speak personally about how difficult it is to design widgets for jQuery UI so that absolutely no choice is left to our users about how accessibility works. Developers will find ways to bend features to their will; if they can get something to work the way they want, they'll do it, regardless of whether it breaks accessibility.
Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events
On Tue, May 1, 2012 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: If we _do_ decide to specify them then their interaction with script running inside the events that changes the focus needs to be very carefully specified, since changing focus will change what cut/copy/paste behavior. I would also need to see some _really_ convincing use cases. I recall moving focus for paste events in order to figure out what is being pasted. I believe this is common in WYSIWYG editors; a new element is created and focus is moved to that element, then the paste occurs, then the element is inspected for the content and the editor does whatever it needs to (like cleaning up junk from pasted Word documents). Obviously if there was a cleaner way to get the contents, like Microsoft APIs for accessing the clipboard, then this wouldn't be needed.
Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events
On Tue, May 1, 2012 at 6:38 PM, Ryosuke Niwa rn...@webkit.org wrote: Does the dataTransfer interface available through via paste event address your use cases? http://dev.w3.org/2006/webapi/clipops/clipops.html#fire-a-clipboard-event http://www.w3.org/TR/html5/dnd.html#the-datatransfer-interface? Yes, that addresses the use case; it will be nice when this is fully supported across browsers. Thanks for pointing it out.
Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events
On Tue, May 1, 2012 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/1/12 6:07 PM, Scott González wrote: I recall moving focus for paste events in order to figure out what is being pasted. I believe this is common in WYSIWYG editors; a new element is created and focus is moved to that element, then the paste occurs, then the element is inspected for the content and the editor does whatever it needs to (like cleaning up junk from pasted Word documents). Obviously if there was a cleaner way to get the contents, like Microsoft APIs for accessing the clipboard, then this wouldn't be needed. Yeah, that seems like an abuse of onbeforepaste. Especially since, again, onbeforepaste doesn't actually fire for all paste methods! I believe I was actually doing this in the paste event. I would move the focus inside the paste event handler (I think I even need to created a new range without my generated element), then use a timeout to check the content afterward. It's been a few years, but I'm pretty sure that's what I was doing. I don't think I even knew about the beforepaste event.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
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
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 2:40 PM, Brian Kardell bkard...@gmail.com wrote: All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I will rest my case :) I feel the same way. I'm not really sure why we would want to use elements and attributes to define the templating language. If the purpose is we can now parse templates using DOM, then I have to wonder if anyone using templates is actually asking for that. I know of two use cases that need to be solved: 1) Templates that cleanly include /script. 2) Generating fragments with arbitrary top-level elements. Are there other use cases that are trying to be solved with template?
