Anne wrote:
but do you see a viable way to get there?
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
To recap
What is= provides:
A
Marcos is working toward a Candidate Recommendation of Manifest for web
application and before that step, we need to publish a Working Draft
for Wide Review [WR] (a WR Draft is equivalent to a Last Call draft
as defined in the consortium's 2005 Process). As such, this is a Call
for Consensus
I tried to explore the synchronous constructor option a bit more. (See
https://wiki.whatwg.org/wiki/CustomElements for details.)
From an HTML parser perspective the main problem would be that
elements with a dash would have to go into the same path that is
basically a special case for /script
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote:
I think being able to extend existing elements has potential value to
developers far beyond accessibility (it just so happens that accessibility
is helped a lot by re-use of existing HTML features.)
I agree with
One additional point, unrelated to accessibility: is also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend template or link.
Here are some examples:
http://jsbin.com/xuheb/3/edit?html,output
On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
faulkner.st...@gmail.com wrote:
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
That
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
That seems rather disingenuous.
where am I being disingenuous?
I don't
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:
On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
wrote:
I think being able to extend existing elements has potential value to
On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn espr...@chromium.org
wrote:
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:
On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com wrote:
composition actually seems to let you express something equally good without
ambiguity more easily except insofar as giving you a really first-class
fallback option if you don't support JS, but... I'm having a really hard
On Jan 29, 2015, at 7:52 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current
Hi all, looking over the W3C TAG packaging draft [1], I would like to see
security through package signing as a use case for packaging.
A hypothetical scenario using Google/Yahoo's End to End email encryption
project:
1. User goes to https://cryptomail.yahoo.com/app.pack for the first time. The
chris palmer wrote:
But other code from the same origin might not be signed, which could
break the security assertion of code signing.
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Paging (future Dr.) Deian Stefan to the ER...
Any thoughts on using COWL for this kind of thing, with a pinned crypto key
as a confinement label to be combined with the regular Origin label?
-Brad
On Thu Jan 29 2015 at 1:43:05 PM Yan Zhu y...@yahoo-inc.com wrote:
chris palmer wrote:
But
On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson bru...@opera.com wrote:
[snip]
a really first-class fallback option if you don't support JS is
vital for the quarter of a billion people who use Opera Mini and the
100 million people who use the Nokia proxy browser. Fallback rather
than
But other code from the same origin might not be signed, which could
break the security assertion of code signing.
The unit of signing should be the same as the unit of isolation, i.e.
the origin. Or, the origin should be expanded to include a 4th
element, the signing key(s). I don't know how to
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says only code signed with this public key runs in
this isolation compartment. Chrome extensions have that
Brad Hill hillb...@gmail.com writes:
Paging (future Dr.) Deian Stefan to the ER...
Any thoughts on using COWL for this kind of thing, with a pinned crypto key
as a confinement label to be combined with the regular Origin label?
Thanks for paging me! I've thought about something like
devdatta wrote:
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says only code signed with this public key runs in
this isolation compartment. Chrome
Would it be possible to meet the security goals without assuming that the
response body is part of the package? See [1] for background on why that's
beneficial.. at least for performance side of the story. I'm picturing a
package description where each resource has a SRI token, plus a signature
to
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
A signed manifest-like package description that lists the hash and
location of every resource seems fine as long as all the resources are
downloaded and verified before running the app. Perhaps this kills
some of the performance benefits
packaging and complicated signing is routine for most installable web apps
and browser extensions; see
https://developer.mozilla.org/en-US/docs/Signing_a_XPI for instance. Developers
who build those might actually want the process to be less complicated.
Given that the packaging spec lists
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
A signed manifest-like package description that lists the hash and
location of every resource seems fine as long as all the resources are
downloaded and
Pardon my french, but the whole idea is ridiculous. Web development is
fluid and flexible. While I most certainly understand the idea and the
need for secured loadable code (AFAIK I brought up this issue about 2
months ago), packaging and complicated signing is counter productive.
What about
24 matches
Mail list logo
