Re: Custom Elements: is=
On 13/06/2015 16:33, Bruce Lawson wrote: On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain text. Browsers that don't know about web components will fall back to button with button this-is-made-much-more-marvellous-by=my-button (or whatever) However, this fallback will only really be useful for very simple cases, where web components have been used to jazz up what essentially is still the element that was extended. And, I would posit, any scripting that was done to act on the all-singing, all-dancing new web component button (if it does anything more than a regular button) would not work for the fallback. Unless it's really just using web components for fancy styling (for instance having a material design button that essentially still works just like a button) - in which case, it makes more sense to work on stylability of standard elements. P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
RE: Custom Elements: is=
From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain text. Of course! I should have thought of that. Léonie. -- Léonie Watson - Senior accessibility engineer @LeonieWatson @PacielloGroup PacielloGroup.com
RE: Custom Elements: is=
From: Tobie Langel [mailto:to...@codespeaks.com] Sent: 12 June 2015 21:26 On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote: Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue [1]. [...] So in summary it's ugly, has a high cognitive load, doesn't express the developers intent (actually even expresses the opposite), is hard to spot when reading code, and is error prone. Hope this helps. :) It does, thank you. At the risk of asking the obvious question, why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button It follows the expected X extends Y convention, and makes it reasonably clear what the attributes have been applied to I think. Léonie.
RE: Custom Elements: is=
From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 14:57 Subject: Re: Custom Elements: is= On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote: I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what they want to achieve (see the extend=parent syntax I wrote earlier). That's true (and I've done exactly this myself). But wouldn't button extendedby=my-button solve that? I think the problem with this would be that it still turns the expected X extends Y convention on its head? It also appears as though the attributes relate to button rather than the element indicated in the extendedby= attribute. Léonie. -- Léonie Watson - Senior accessibility engineer @LeonieWatson @PacielloGroup PacielloGroup.com
Re: Custom Elements: is=
On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote: I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what they want to achieve (see the extend=parent syntax I wrote earlier). That's true (and I've done exactly this myself). But wouldn't button extendedby=my-button solve that? b
Re: Clipboard API: remove dangerous formats from mandatory data types
Hello all, I think a good solution would then be that UAs do a transcoding, or? (so the spec should recommend doing it) I understand that the right-menu copy image function has the same problem except if that one does transcoding (and it probably does, to offer more native flavours). That would work fine against attacking pictures that would overflow some older picture processors. For those graphic freaks which need the exact bytes (e.g. with a particular profile etc), I think they can expect the web-app to offer a download for which there's enough dialogs and protection. Whether an unfiltered picture file should be expected by copy after some security-dialog-confirmed process, I do not know. Maybe using octet-stream is the solution? thanks Paul On 11/06/15 08:31, Hallvord Reiar Michaelsen Steen wrote: On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com mailto:dch...@google.com wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif copying images to the clipboard is an important use case. Do you have any suggestions for how we could meet this use case in a safer way? For example, would it be safe and easy to add a little bit of magic to make clipboardData.items.add(canvasElement) put a PNG on the clipboard? Perhaps copying a rendered imgElement should work too? -Hallvord signature.asc Description: OpenPGP digital signature
Re: Custom Elements: is=
On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson lwat...@paciellogroup.com wrote: Is there a succinct explanation of why the is= syntax is disliked? Rather than button is=my-button/button you want my-button/my-button that just gets all the button goodness through composition/inheritance. Also the fact that you need form is=my-form to be able to submit custom elements is something we should fix in the design of form. That is= can make certain hacks a little simpler is nice, but that's not enough to justify standardizing it. I have the feeling we're going in circles though, since the arguments on both sides have been made repeatedly for the past x years. -- https://annevankesteren.nl/
Re: Custom Elements: is=
Folks, I agree with Anne that we've been having a somewhat circular re-discovery of the pros/cons here. I believe that the best way to address this is to capture all of these points in one doc -- this would be a just a little extra work for the current participants, but super awesome for the future folk. For example, Domenic started such a doc for another custom elements contentious bit: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md. Please help break the cycle of re-discovery :) :DG
Re: Custom Elements: is=
On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain text. Browsers that don't know about web components will fall back to button with button this-is-made-much-more-marvellous-by=my-button (or whatever) b
Re: Custom Elements: is=
Doc in progress at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md On Sat, Jun 13, 2015 at 8:50 AM, Dimitri Glazkov dglaz...@google.com wrote: Folks, I agree with Anne that we've been having a somewhat circular re-discovery of the pros/cons here. I believe that the best way to address this is to capture all of these points in one doc -- this would be a just a little extra work for the current participants, but super awesome for the future folk. For example, Domenic started such a doc for another custom elements contentious bit: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md. Please help break the cycle of re-discovery :) :DG
Re: Clipboard API: remove dangerous formats from mandatory data types
On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn espr...@chromium.org wrote: I don't think the clipboard should forbid inserting image data, there's so many ways to compromise desktop software. ex. pasting text/html into Mail.app might even do it. This API shouldn't be trying to prevent that. Well, the only *really* foolproof way to avoid software vulnerabilities is not using a computer ;). I'd still like to see concrete suggestions (like suggested algorithms or clipboardData methods) that we might consider for a safer solution - if we can come up with any. -Hallvord
Re: Custom Elements: is=
On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote: Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue [1]. Esthetics aside, the main issue it is takes the concept of inheritance developers are familiar with and stands it on its head. The idea with inheritance is that you build a new object and it happens to inherit from another one, so for example: my-button extends=button makes a lot of sense. Clearly, you're building a new element that extends the capabilities of the existing button object. With the is= syntax, however, what it is you're doing isn't clear at all: button is=my-button What's the message here? Oh this is just a button. Oh wait no it's not, it's a my-button. But does it actually inherit from button? Mmm. Not clear from the syntax. Further more, what about when you add a bunch of extra attributes in there: button value=45 class=button button-large is=my-button id=cta / It becomes hard to spot that this element isn't actually a traditional button. Things get easily lost when scanning code. I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what they want to achieve (see the extend=parent syntax I wrote earlier). So in summary it's ugly, has a high cognitive load, doesn't express the developers intent (actually even expresses the opposite), is hard to spot when reading code, and is error prone. Hope this helps. :) --tobie
Re: Clipboard API: remove dangerous formats from mandatory data types
On Thu, Jun 11, 2015 at 7:51 PM, Wez w...@google.com wrote: Hallvord, The proposal isn't to remove support for copying/pasting images, but to restrict web content from placing compressed image data in one of these formats on the clipboard directly - there's no issue with content pasting raw pixels from a canvas, for example, since scope for abusing that to compromise the recipient is extremely limited by comparison to JPEG, PNG or GIF. Well, but as far as I can tell we don't currently *have* a way JS can place pixels from a canvas on the clipboard (except by putting a piece of data labelled as image/png or similar there). So if you're pushing back against the idea that JS can place random data on the clipboard and label it image/png, how exactly would you propose JS-triggered copy of image data to work? Say, from a CANVAS-based image editor? -Hallvord
