bugzilla | 1 Mar 04:58 2015
Picon

[Bug 28117] New: Clarify timeout in case Preflighted CORS requests

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28117

            Bug ID: 28117
           Summary: Clarify timeout in case Preflighted CORS requests
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XHR
          Assignee: annevk@...
          Reporter: naren@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

The spec needs to specify how timeout should behave when there is Preflight
OPTIONS request. It seemed logical to assume xhr.timeout = timeout (OPTIONS +
ACTUAL) request

The way browsers implement is non intuitive. Say I set timeout as 1000 (1sec).
The browser sets 1000ms timeout for OPTIONS and 1000ms timeout for ACTUAL
request. 

Clarifying that in the spec would enable browsers to implement the right way.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.
(Continue reading)

Vincent Scheib | 26 Feb 20:21 2015
Picon

Re: Pointer lock spec

Thanks, Philip, changes made.

On Thu, Feb 26, 2015 at 10:58 AM, Philip Jägenstedt <philipj-4vTceeIZeJ0AvxtiuMwx3w@public.gmane.org> wrote:
Also, the EventHandler type should not be nullable, it's already
typedef'd to be nullable in https://html.spec.whatwg.org/#eventhandler

On Fri, Feb 27, 2015 at 1:56 AM, Philip Jägenstedt <philipj-4vTceeIZeJ0AvxtiuMwx3w@public.gmane.org> wrote:
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
>
> The section "Element Interface" should be "Extensions to the Element
> Interface" to match the other sections, and because it's true :)
>
> Philip

Phillips, Addison | 26 Feb 17:54 2015

[manifest] I18N review in progress

Dear webapps,

The Internationalization Working Group is reviewing [2] your specification "Manifest for web
application" per your request [1]. We were unable to complete our review during this week's
teleconference. Our next teleconference is scheduled for 5 March, which is your deadline for comments.
This note is to let you know that we will have some comments for you.

There are two concerns that I want to note in advance that perhaps you can clarify:

1. There is no localization model or apparently a means of finding out about the availability of different
languages of a given app, including alternate icons, names, short names and such. I'm curious as to
whether there is an intention to provide this capability? What do authors of localized web applications do?

2. There is no provision for language or bidirectional control for natural language text inside a
manifest. For example, you can't tag the name of an app as being in Japanese (necessary for correct font
selection by the host environment, for example) or to set the base direction of the name (so that mixed
right-to-left and left-to-right text is drawn correctly).

Thanks (for I18N),

Addison

[1] https://lists.w3.org/Archives/Public/www-international/2015JanMar/0067.html

[2] https://www.w3.org/International/wiki/Review_radar 

Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Picon

Re: Better focus support for Shadow DOM

Hi Chaals,

Thanks for the comment.
Honestly I'm not so familiar with ARIA/a11y requirements but the problem sounds to apply Shadow DOMs overall,
not specific to the problem I'm trying to address here.  Do you have any concrete cases that this (isTabStop feature et al.)
can regress or degenerate (or improve?) any a11y?

For issue 27965, I commented on it with an example.


On Thu, Feb 19, 2015 at 7:45 PM, <chaals-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
Hi,
 
I noted the bugs, this thread, and the document in the HTML accessibility wiki where I am trying to collate stuff about focus navigation and similar keyboard access issues (in what might yet be a vain attempt to really improve the situation which is overall pretty dismal still): https://www.w3.org/WAI/PF/HTML/wiki/Keyboard
 
19.02.2015, 04:56, "Takayoshi Kochi (河内 隆仁)" <kochi-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>:
[Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation
 
 
I am not sure if this really is a problem (which might just be my brain going slowly). See my comment for more details, but it isn't clear to me that this needs to be fixed. On further reflection, I wonder if the point is where the author has explicitly marked tabindex="-1" - and how this relates to comound ARIA controls...
 
 
cheers
 
Focus on shadow host should slide to its inner focusable node

On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) <kochi <at> google.com> wrote:
Hi,
 
For shadow DOMs which has multiple focusable fields under the host,
the current behavior of tab navigation order gets somewhat weird
when you want to specify tabindex explicitly.
 
This is the doc to introduce a new attribute "delegatesFocus" to resolve the issue.
https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
 
Any comments are welcome!
--
Takayoshi Kochi


 
--
Takayoshi Kochi
 
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org - - - Find more at http://yandex.com
 



--
Takayoshi Kochi
Arthur Barstow | 24 Feb 21:37 2015
Picon

[admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10

The registration page for the April 24 Web Components f2f meeting at 
Google's Mount View CA office is now open:

<https://www.w3.org/2002/09/wbs/42538/webcomponents-042015/>

The meeting/agenda page is: 
<https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting>.

Please register by April 10.

-Thanks, AB

bugzilla | 24 Feb 16:50 2015
Picon

[Bug 28092] New: [Custom]: Clarify in informative note that cloning/importing also enqueues created callback

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092

            Bug ID: 28092
           Summary: [Custom]: Clarify in informative note that
                    cloning/importing also enqueues created callback
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: dglazkov@...
        QA Contact: public-webapps-bugzilla@...
                CC: annevk@..., mike@..., public-webapps@...
            Blocks: 14968

"a conforming UA must run enqueue created callback whenever creating a custom
element."

The section title and informative note only talk about parser-driven element
creation, but it doesn't mention cloning/importing that is also affected by the
normative statement.

--

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

bugzilla | 24 Feb 00:28 2015
Picon

[Bug 28086] New: [Shadow] (assuming iframes should work inside shadow DOM) Should the contentWindow objects of iframes in shadow DOM show up in window.frames?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28086

            Bug ID: 28086
           Summary: [Shadow] (assuming iframes should work inside shadow
                    DOM) Should the contentWindow objects of iframes in
                    shadow DOM show up in window.frames?
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: bugs@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

.

--

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

Henri Sivonen | 23 Feb 16:15 2015
Picon

Re: CORS performance

On Tue, Feb 17, 2015 at 9:31 PM, Brad Hill <hillbrad@...> wrote:
> I think it is at least worth discussing the relative merits of using a
> resource published under /.well-known for such use cases, vs. sending
> "pinned" headers with every single resource.

FWIW, when CORS was designed, the Flash crossdomain.xml design (which
uses a well-known URL though not under /.well-known) already existed
and CORS deliberately opted for a different design.

It's been a while, so I don't recall what the reasons against adopting
crossdomain.xml or something very similar to it were, but considering
that the crossdomain.xml design was knowingly rejected, it's probably
worthwhile to pay attention to why.

--

-- 
Henri Sivonen
hsivonen@...
https://hsivonen.fi/

Anne van Kesteren | 23 Feb 10:27 2015
Picon

Custom elements: synchronous constructors and cloning

I've been continuing to explore synchronous constructors for custom
elements as they explain the parser best. After reading through
https://speakerdeck.com/vjeux/oscon-react-architecture I thought there
might be a performance concern, but Yehuda tells me that innerHTML
being faster than DOM methods is no longer true.

Dimitri pointed out that cloning might be problematic. The
https://dom.spec.whatwg.org/#concept-node-clone operation is invoked
from numerous range operations that might not expect side effects.
Here are the alternatives to consider:

1) If we run the constructor synchronously, even during cloning. If
the constructor did something unexpected, is that actually
problematic? It is not immediately clear to me what invariants we
might want to preserve. Possibly it's just that the code would get
more complicated when not self-hosted? Similar to mutation events? If
someone has a list of reasons in mind that would be appreciated. This
type of question keeps popping up.

2) When running the constructor DOM methods that cause mutations
throw. They are locked. This might not work well due to shadow DOM.

3) We use structured cloning. Custom state stored behind an
Element.state symbol.

4) We use structured cloning, but for custom state a callback is
invoked with similar timing to the callbacks part of custom elements
today.

Both 3 and 4 seem the least invasive to the current state of play, but
it would be good to know why we want to preserve the status quo for 1
and 2.

--

-- 
https://annevankesteren.nl/

bugzilla | 23 Feb 06:24 2015
Picon

[Bug 28079] New: [Shadow]: inappropriate reference to CSS3-UI nav-index spec in focus navigation order

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28079

            Bug ID: 28079
           Summary: [Shadow]: inappropriate reference to CSS3-UI nav-index
                    spec in focus navigation order
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: kochi@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...
            Blocks: 14978

The current shadow DOM spec specifies the focus navigation order of
elements in the shadow tree using CSS3 UI's "nav-index" property[1]
(more specifically in its algorithm 1.3.2 and 2.3, the spec refers to
"auto" for nav-index CSS property).

It's better to rewrite this part to refer to HTML spec, rather than
CSS3 UI spec.

The property is considered "at risk" in the CSS3 UI spec, and might not
be adopted as is in the current spec draft.  I found some discussion in
CSS WG's meeting notes[2].

As far as I read the CSS3 UI spec, the "auto" value corresponds to the
behavior of HTML attribute "tabindex" with its value 0 (cf, the spec
is [3] or [4]), which is already implemented in most browsers and the
spec is stable.

[1] http://www.w3.org/TR/css3-ui/#nav-index
[2] https://lists.w3.org/Archives/Public/www-style/2015Jan/0406.html
[3]
https://html.spec.whatwg.org/multipage/interaction.html#the-tabindex-attribute
[4]
http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-the-tabindex-attribute

--

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

bugzilla | 21 Feb 20:49 2015
Picon

[Bug 28069] New: [Shadow]: Should Text.getDestinationInsertionPoints() be specified?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28069

            Bug ID: 28069
           Summary: [Shadow]: Should Text.getDestinationInsertionPoints()
                    be specified?
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: philipj@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...
            Blocks: 14978

Blink has getDestinationInsertionPoints() on Element and Text, but only Element
is in the spec:
http://w3c.github.io/webcomponents/spec/shadow/#extensions-to-element-interface

--

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


Gmane