1) Are form elements (input, select, textarea) inside a shadow dom
considered when submitting a form?
The Shadow DOM spec doesn't say anything about this. Therefore,
form elements should be in the same node tree.
For example, suppose a form element is in the node tree A. In this
case,
On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte vitteayme...@gmail.com
wrote:
Does your experimentation pipe the XHR stream to MSE? Obviously that
should be the target for yt, this would be a first real application of the
Streams API.
It's not yet updated to use the new Streams. Here's our
Ondrej,
The short answer to whether input inside shadow root under a form will
be sent or not is No.
The node tree mentioned in Hayato's mail means that form and input
belong to different trees.
Only elements in the same tree as form will be considered for submission.
So you don't have to worry
On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára ondrej.z...@firma.seznam.cz
wrote:
1) Are form elements (input, select, textarea) inside a shadow dom
considered when submitting a form?
The Shadow DOM spec doesn't say anything about this. Therefore,
form elements should be in the
The short answer to whether input inside shadow root under a form
will be sent or not is No.
The node tree mentioned in Hayato's mail means that form and input
belong to different trees.
Sweet, thanks for explanation.
(Now only the second question remains...)
Sincerely,
O. Zara
On Thu Sep 11 2014 at 4:04:27 PM Hayato Ito hay...@chromium.org wrote:
On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára ondrej.z...@firma.seznam.cz
wrote:
1) Are form elements (input, select, textarea) inside a shadow dom
considered when submitting a form?
The Shadow DOM spec
But I suppose that should be one of the first use case for Google to
introduce streams with MSE, no?
To be more clear about what I mean by back pressure for things coming
from outside of the browser:
- XHR: the Streams API should define how xhr gets chunks using Range
according to the flow
On Thursday, September 11, 2014, Robin Berjon ro...@w3.org
javascript:_e(%7B%7D,'cvml','ro...@w3.org'); wrote:
On 10/09/2014 18:48 , Marcos Caceres wrote:
This is a formal objection to publication of this specification.
The rationale for the objection was already sent to the wwwprocess list.
On Sep 9, 2014, at 6:31 AM, Johannes Wilm johan...@fiduswriter.org wrote:
Absolutely. if this division means we can get into a saner place faster (and
with a higher likelihood that it will actually happen) then I am all for it.
Of course the long-term future of the web should be taken into
Hi Marcos,
On 11/09/2014 17:19 , Marcos Caceres wrote:
Only once I have clear answers to the following (and see actual proof).
I know you already addressed some of this in your previous email to
Dominic.
I will address your points below, but I will repeat what I told Domenic:
I don't think
On 2014-09-11 17:19, Marcos Caceres wrote:
...
5. What indicators (e.g., the big red box) will be put into the spec to
indicate that the WHATWG version is the canonical version?
...
It's my understanding that the intent is to actually make technical
changes, as indicated in:
This
On Thu, Sep 11, 2014 at 5:58 PM, Julian Reschke
julian.resc...@greenbytes.de wrote:
It's my understanding that the intent is to actually make technical changes,
as indicated in:
This specification documents current RFC 3986 and RFC 3987 handling in
contemporary Web browser implementations. As
On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote:
In which case the WHATWG version wouldn't be canonical anymore anyway.
It would be for implementers.
Only those implementers that can afford to staff a team to keep up
with a moving target. That's not all potential
On Thu, Sep 11, 2014 at 6:52 PM, Mark Baker dist...@acm.org wrote:
Only those implementers that can afford to staff a team to keep up
with a moving target. That's not all potential implementers.
What do you mean moving target? In general we only change
specifications if there's something wrong
On 9/11/14, 12:52 PM, Mark Baker wrote:
On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote:
In which case the WHATWG version wouldn't be canonical anymore anyway.
It would be for implementers.
Only those implementers that can afford to staff a team to keep up
with a
On Thu, Sep 11, 2014 at 2:20 PM, Robin Berjon ro...@w3.org wrote:
On 11/09/2014 00:14 , Glenn Adams wrote:
WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.
This is blatant trolling as well as factually
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25310
Mounir Lamouri mou...@lamouri.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
Mounir and Marcos would like to publish a LCWD of The Screen Orientation
API and this is a Call for Consensus to do using the latest ED (not yet
in the LCWD template) as the basis:
https://w3c.github.io/screen-orientation/
The spec has three open Issues, all labeled Future + Enhancement and
On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow art.bars...@gmail.com wrote:
Mounir and Marcos would like to publish a LCWD of The Screen Orientation API
and this is a Call for Consensus to do using the latest ED (not yet in the
LCWD template) as the basis:
On Thu, Sep 11, 2014 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
Also, I can't find any normative definition of if orientation.angle
should increase or decrease if the user rotates a device 90 degrees
clockwise?
My bad, I see it now. Given how easy this is to get wrong, it might be
worth
20 matches
Mail list logo
