=[xhr]

2015-01-30 Thread LOUIFI, Bruno 
Hi,

I am really disappointed when I saw in Chrome debugger that the 
XMLHttpRequest.open() is deprecating the synchronous mode. This is was the 
worst news I red since I started working on web applications.

I don't know if you release the negative impacts on our professional 
applications. We made a huge effort creating applications on the web and also 
providing JavaScript APIs that behave as Java APIs in order to help developers 
migrating from java to JavaScript technology.

So please reconsider your decision. Our customers use APIs for their 
professional business. You don't have right to break their applications.

Regards,

Bruno Louifi

Senior Software Developer

Re: Minimum viable custom elements

2015-01-30 Thread Bruce Lawson 
On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:
>  And we have a proposal to do both of these things: decorators [1]

yes, indeed. What is the status of decorators? Last I looked, it had
been removed from the "web components" umbrella, so I thought it had
been sent to a farm upstate, but I haven't been following its progress
particularly closely.

>
> One more thing.  I would really like if we could stop making claims such as
> web components as currently spec'ed magically improves accessibility because
> it's doing a huge disservice to the future of the Web accessibility.

I'm not certain anyone has made the claim that anything's "magically
improved" ...


They
> don't.  Far from it.  I've pointed out numerous issues with them over the
> last couple of years but none of them have been adequately addressed.

could you provide a pointer to them, please?

bruce

Re: =[xhr]

2015-01-30 Thread Frederik Braun 
Hi,

Thank you for your feedback. Please see the archives for previous
iterations of this discussion, e.g.

(and click "next in thread").


On 29.01.2015 21:04, LOUIFI, Bruno wrote:
> Hi,
> 
> I am really disappointed when I saw in Chrome debugger that the
> XMLHttpRequest.open() is deprecating the synchronous mode. This is was
> the worst news I red since I started working on web applications.
> 
> I don’t know if you release the negative impacts on our professional
> applications. We made a huge effort creating applications on the web and
> also providing JavaScript APIs that behave as Java APIs in order to help
> developers migrating from java to JavaScript technology.
> 
> So please reconsider your decision. Our customers use APIs for their
> professional business. You don’t have right to break their applications.
> 
> Regards,
> 
> Bruno Louifi
> 
> Senior Software Developer
>

Re: Minimum viable custom elements

2015-01-30 Thread Steve Faulkner 
I am not championing is= as the answer to all the worlds ills, but it does
provide *examples* of built in features that I believe are critical to
robust accessibility support in web components:

which are:
roles/state and property mapping from existing attributes (disabled,
required etc)
platform/browser standard interaction behaviours (keyboard etc)
ability to provide an accessible name, and  elements (that are
labelable) using standard HTML

In this radio and checkbox example (view in chrome)
https://rawgit.com/alice/web-components-demos/master/index.html
(which has been referenced several times in this thread, but no one has
critiqued to my knowledge) all of the above are evident, while at the same
time appearing to overcome the issue of standard control fugliness

If there are better ways to achieve the built in features which support
robust accessibility I am all for it. ,

--

Regards

SteveF
HTML 5.1 

On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:

>
> On Jan 29, 2015, at 7:52 AM, Steve Faulkner 
> wrote:
> On 29 January 2015 at 15:37, Anne van Kesteren  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 seems rather disingenuous.
>>
>
> where am I being disingenuous?
>
> I don't understand how the various pieces are pulled together to make an
> element work in browsers to an extent to be able to offer possible
> technical solutions. If I did I would.
>
>
> I think there is a bit of miscommunication here.
>
> Correct me if I'm wrong but I think you're trying to fix the problem of
> Web developers writing their own UI widgets and components and they're
> often inaccessible because they didn't set ARIA roles right, etc…
>
> If that's the problem you're trying to solve here, then what you need is
> shadow DOM, not custom elements.  As someone who cares about accessibility
> deeply, I want to solve this problem too.  However, like Anne pointed out
> in earlier threads, authors aren't going to start using custom elements to
> implement those fancy UI widgets currently implemented via div's and span's
> using is=~ attribute since custom elements doesn't provide any mechanism to
> change the appearance of a builtin element.  Shadow DOM, on the other hand,
> is one proposed mechanism to replace the appearance of a builtin element by
> way of replacing the contents of the element via a shadow tree.  Now, if
> we're using shadow DOM to change the appearance of a builtin element, then
> choosing which appearance to use in the HTML markup via a content attribute
> is a layering violation.  We should be doing that in CSS instead.  And we
> have a proposal to do both of these things: decorators [1]
>
> One more thing.  I would really like if we could stop making claims such
> as web components as currently spec'ed magically improves accessibility
> because it's doing a huge disservice to the future of the Web
> accessibility.  They don't.  Far from it.  I've pointed out numerous issues
> with them over the last couple of years but none of them have been
> adequately addressed.
>
> [1]
> https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section
>
> - R. Niwa
>
>

[Bug 27931] New: Override 'flex' and 'transform' styling

2015-01-30 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27931

Bug ID: 27931
   Summary: Override 'flex' and 'transform' styling
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Fullscreen
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: fal...@chromium.org, m...@w3.org, phil...@opera.com,
public-webapps@w3.org, r...@ocallahan.org,
sim...@opera.com

The conclusion from
https://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg287 seems
to be that the rendering section should override 'flex' and 'transform'.
Presumably as follows:

  *|*:not(:root):fullscreen {
flex:none !important;
transform:none !important;
  }

If anyone disagrees with this now would be a good time to speak up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Minimum viable custom elements

2015-01-30 Thread Anne van Kesteren 
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
 wrote:
> In this radio and checkbox example (view in chrome)
> https://rawgit.com/alice/web-components-demos/master/index.html
> (which has been referenced several times in this thread, but no one has
> critiqued to my knowledge) all of the above are evident, while at the same
> time appearing to overcome the issue of standard control fugliness

The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397

Which is much much simpler and requires none of the HTML imports,
shadow tree, and all that script. It's also fully accessible and
backwards compatible to the same extent. And shows that the real
tidbit here is -webkit-appearance and not custom elements at all.

(For identical styling you need to move the background-image line into
a distinct input:checked selector block. I messed up a bit with copy
and pasting.)


-- 
https://annevankesteren.nl/

Re: Security use cases for packaging

2015-01-30 Thread Daniel Kahn Gillmor 
On Fri 2015-01-30 01:50:43 -0500, Yan Zhu wrote:
> Say that resource Y is a javascript file that listens for users typing
> in password fields and shows them a warning if the password is
> weak. The user verifies and loads the HTML page that includes Y but an
> attacker then blocks the request to fetch Y, so the user picks a weak
> password.
>
> My intuition is that most developers think about the security of their
> app as a whole, not the security of their app minus
> any-given-subset-of-resources.

I see what you're saying -- and javascript that is directly embedded in
the app would all definitely need to be loaded first (since we don't
know how it would affect the rest of the application).  I was thinking
of other resources that might be invoked or loaded later, via XHR or
dynamic script load other requests.

I suppose the question then arises of what to do if the app triggers an
XHR or dynamic script load for a piece of signed content, and that
signed content can't be fetched, the entire application would have to
block or something to avoid the scenario you describe.  That kind of UX
doesn't sound very web-like :/

--dkg

Re: Security use cases for packaging

2015-01-30 Thread Chris Palmer 
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu  wrote:

> Say that resource Y is a javascript file that listens for users typing in 
> password fields and shows them a warning if the password is weak. The user 
> verifies and loads the HTML page that includes Y but an attacker then blocks 
> the request to fetch Y, so the user picks a weak password.

The application developer could cope with this in the top-layer code:

===

var passwordChecker = null;
...



if (null == passwordChecker) {
// handle failure of security dependency
}

===

Just as a native application developer should do:

===
void* passwordChecker = dlopen("password-checker.so", ...);
if (NULL == passwordChecker) {
// handle failure of security dependency
}
===

But,

> My intuition is that most developers think about the security of their app as 
> a whole, not the security of their app minus any-given-subset-of-resources.

You're probably right, about both web developers and native code developers.

But, if we provide a declarative interface for the package format that
allows developers to declare that a given dependency should be
pre-loaded when possible and mandatorily pre-loaded, they might be
more likely to use that than to write the tedious error-handling code
like that above. I.e. we can create good affordances, and thus get the
benefits of security and performance most of the time.

Re: Minimum viable custom elements

2015-01-30 Thread Ryosuke Niwa 

> On Jan 30, 2015, at 1:02 AM, Bruce Lawson  wrote:
> 
> On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:
>> And we have a proposal to do both of these things: decorators [1]
> 
> yes, indeed. What is the status of decorators? Last I looked, it had
> been removed from the "web components" umbrella, so I thought it had
> been sent to a farm upstate, but I haven't been following its progress
> particularly closely.

I think it got removed because we couldn’t figure out the life-cycle story.  
Since decorators are bound by CSS, they need to be instantiated at the time of 
style resolution, which is highly implementation dependent.

- R. Niwa

Re: Minimum viable custom elements

2015-01-30 Thread Ryosuke Niwa 

> On Jan 30, 2015, at 10:22 AM, Alice Boxhall  wrote:
> 
> On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren  > wrote:
> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
> mailto:faulkner.st...@gmail.com>> wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html 
> > 
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the same
> > time appearing to overcome the issue of standard control fugliness
> 
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 
> 
> 
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
> 
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)
> 
> Sure, that works for this example (which was created in a huge rush at the 
> last minute before a talk, like probably 90% of my productive work), but I 
> don't believe it wouldn't work for 
> http://www.polymer-project.org/components/paper-radio-button/demo.html 
>  
> which has a fancy animation for changing states.

It doesn’t but how does custom elements solve that problem?  This example 
doesn’t even seem to use “is” and manually sets ARIA attributes.  Could you 
clarify exactly which accessibility issues custom elements would solve in this 
example?

> So, I naively ask, what's stopping us from standardising something like 
> -webkit-appearance: none? I think that a bunch of the most common 
> accessibility issues we see today come from people (quite justifiably) 
> re-implementing standard HTML elements in order to get the styling they need 
> - with or without using Custom Elements.

Indeed.  It would be really useful to solve this problem either with a CSS 
property like -webkit-appearance or decorator.  Perhaps Tantek or Fantasai 
could enlighten us.

Relevant URLs:
https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
 

https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html 

https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html

- R. Niwa

Re: Minimum viable custom elements

2015-01-30 Thread fantasai 

On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:



On Jan 30, 2015, at 10:22 AM, Alice Boxhall mailto:aboxh...@google.com>> wrote:

The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397

[...]

So, I naively ask, what's stopping us from standardising something like 
-webkit-appearance: none? I think that a bunch of
the most common accessibility issues we see today come from people (quite 
justifiably) re-implementing standard HTML
elements in order to get the styling they need - with or without using Custom 
Elements.


-webkit-appearance: none isn't a proprietary extension, it's a prefixed
version of something that was once in a standards-track document. It
got removed because there were serious design problems with the original
idea, but some values stuck around.


Indeed.  It would be really useful to solve this problem either with a CSS 
property like -webkit-appearance or decorator.
  Perhaps Tantek or Fantasai could enlighten us.

Relevant URLs:
https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html
https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html


I think you caught the important points right there.

Tantek and Florian are actively working on updating the CSS3 UI
draft right now, so this might come up at the CSSWG f2f in a
couple weeks.

~fantasai

Re: Minimum viable custom elements

2015-01-30 Thread Tantek Çelik 
I'm tracking the state of requests for 'appearance' here:

https://wiki.csswg.org/spec/css4-ui#appearance

Feel free to directly edit that wiki page and add more concrete data /
research that you think will help make a decision in terms of design
etc.

For now, there is insufficient data to show anyhing of any reasonable
interop for this property, hence it is still postponed at best.

Thanks,

Tantek

tags: [css-ui] [css3-ui] [cssui]



On Fri, Jan 30, 2015 at 8:58 PM, fantasai  wrote:
> On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:
>>
>>
>>> On Jan 30, 2015, at 10:22 AM, Alice Boxhall >> > wrote:
>>>
>>> The only way it overcomes that is by relying on a proprietary
>>> extension called -webkit-appearance that is not standardized and does
>>> not work reliably across browsers. Furthermore, it's not at all clear
>>> to me why that example needs custom elements to begin with. If we
>>> assume this proprietary extension exists, we can just do this:
>>>
>>> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> [...]
>>>
>>> So, I naively ask, what's stopping us from standardising something like
>>> -webkit-appearance: none? I think that a bunch of
>>> the most common accessibility issues we see today come from people (quite
>>> justifiably) re-implementing standard HTML
>>> elements in order to get the styling they need - with or without using
>>> Custom Elements.
>
>
> -webkit-appearance: none isn't a proprietary extension, it's a prefixed
> version of something that was once in a standards-track document. It
> got removed because there were serious design problems with the original
> idea, but some values stuck around.
>
>> Indeed.  It would be really useful to solve this problem either with a CSS
>> property like -webkit-appearance or decorator.
>>   Perhaps Tantek or Fantasai could enlighten us.
>>
>> Relevant URLs:
>>
>> https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
>> https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html
>> https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
>> https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html
>
>
> I think you caught the important points right there.
>
> Tantek and Florian are actively working on updating the CSS3 UI
> draft right now, so this might come up at the CSSWG f2f in a
> couple weeks.
>
> ~fantasai