On Nov 7, 2014, at 12:25 PM, Ryosuke Niwa wrote:
> On Nov 5, 2014, at 7:54 AM, cha...@yandex-team.ru wrote:
>> we have had a (northern) spring meeting in California for the last few
>> years, co-located with HTML.
>>
>> The HTML group is considering having a meetin
> On Dec 17, 2014, at 6:16 PM, Brian Kardell wrote:
>
> On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa <mailto:rn...@apple.com>> wrote:
>
>> On Dec 17, 2014, at 3:18 PM, Brian Kardell > <mailto:bkard...@gmail.com>> wrote:
>>
>> On Wed,
> On Dec 17, 2014, at 3:18 PM, Brian Kardell wrote:
>
> On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa <mailto:rn...@apple.com>> wrote:
> Hi Brian,
>
> The WebKit team has given a lot of feedback over the years on the Shadow DOM
> spec. We wouldn't have d
Hi Brian,
The WebKit team has given a lot of feedback over the years on the Shadow DOM
spec. We wouldn't have done that if we didn't care about it. :) We're excited
to hear that Mozilla is planning to give more feedback on Custom Elements and
Shadow DOM because we feel that much of their feed
On Nov 5, 2014, at 7:54 AM, cha...@yandex-team.ru wrote:
> we have had a (northern) spring meeting in California for the last few years,
> co-located with HTML.
>
> The HTML group is considering having a meeting in may(ish) 2015 in Paris -
> and there is an offer to host such a meeting.
>
> So
On Oct 28, 2014, at 2:23 PM, Anne van Kesteren wrote:
> On Tue, Oct 28, 2014 at 8:04 PM, Travis Leithead
> wrote:
>> There was interest in the room at TPAC at making this a new unique spec
>> deliverable under webapps.
>
> A single specifiation for innerText? Or the underlying primitive that
>
On Oct 6, 2014, at 10:21 AM, Jarek Foksa wrote:
>> On 2014-10-06, at 18:24, James M. Greene wrote:
>> This only thing about this approach that is slightly inconsistent with the
>> rest of the Web Platform is assuming that the `this` context within the
>> handler will be set to the element, rat
On Sep 20, 2014, at 5:52 AM, Arthur Barstow wrote:
> Hi Ryosuke, Ben, Kenji, All,
>
> I'm looking for feedback about moving the Selection API [ED] to First Public
> Working Draft (FPWD) ...
>
> A `rule of thumb` I generally use when considering if a spec is ready for a
> FPWD is if the featur
Hi,
Is either one of you working on innerText specification?
(http://lists.w3.org/Archives/Public/www-archive/2014Mar/0008.html)
I think we need it for the selection API specification because the concept of
being “visually equivalent” and selection.toString need to be defined in terms
of it.
-
On Sep 15, 2014, at 1:09 PM, Jonas Sicking wrote:
> On Sun, Sep 14, 2014 at 5:54 AM, Dale Harvey wrote:
>> websites can already trivially build editors that use copy and paste within
>> the site itself, the entire problem is that leads to confusing behaviour
>> when the user copies and pastes o
On Sep 9, 2014, at 6:31 AM, Johannes Wilm 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 consideration
> as
; I don’t understand the difference. setBaseAndExtent would then set all 4 of
> these properties of selection? Do you have a definition to use for this?
>
> From: Ryosuke Niwa [mailto:rn...@apple.com]
> Sent: Wednesday, August 6, 2014 12:43 PM
> To: James M. Greene
> Cc: Ben P
On Sep 4, 2014, at 6:46 AM, Tab Atkins Jr. wrote:
> On Thu, Sep 4, 2014 at 5:43 AM, Arthur Barstow wrote:
>> Hi Editors, All,
>>
>> Speaking of ED boilerplate data ... do we want to try to get some
>> consistency regarding boilerplate data in our EDs?
>>
>> We have quite a bit of variation no
length ([DOM4]). Otherwise, it must create a new range,
>> set ([DOM4]) its start to (baseNode, baseOffset) and its and end to
>> (extentNode, extentOffset), and set the context object's range to the
>> newly-created range.
>>
>>
>>
>> From: Ben Peter
On Aug 4, 2014, at 7:28 PM, Ben Peters wrote:
> Cross-posted: Editing TF, IndieUI TF, WebApps WG
>
> In order to solve the broad issue of User Intentions, we have compiled below
> a list of User Intentions derived from all of the sources of intention-style
> events that I am aware of. I agree
On Jul 22, 2014, at 3:17 PM, Ben Peters wrote:
> Semi-trusted events in the Clipboard API spec [1] are a potential solution to
> an important problem- sites should be able to use the same infrastructure
> (clipboard events) with their own triggers (button with execCommand(‘paste’)
> as browser
://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0011.html
>
> On Mon, Jun 30, 2014 at 10:33 PM, Johannes Wilm
> wrote:
>>
>>
>>
>> On Tue, Jul 1, 2014 at 4:39 AM, Ryosuke Niwa wrote:
>>>
>>> On Jun 30, 2014, at 1:43 PM, Johannes Wilm
On Jul 2, 2014, at 9:26 AM, Domenic Denicola
wrote:
> From: Ryosuke Niwa
>
>> Snapshotting a specification is valuable for implementors as well. If I
>> refer to a living standard page, then fragment ID or terminology used in the
>> specification may change in 5-10
On Jun 26, 2014, at 9:18 AM, Ian Hickson wrote:
> On Wed, 25 Jun 2014, Glenn Adams wrote:
>> On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson wrote:
>>>
>>> Compraing implementations to anything but the very latest draft is not
>>> only a waste of time, it's actively harmful to interoperability. A
On Jul 2, 2014, at 3:57 AM, Brian Di Palma wrote:
> I gave a workshop on ES6 and Web Components at a small conference in
> London and there was positive feedback on Custom Elements.
> People liked them, felt the component approach was a good way to model
> web applications. Then again React has si
On Jul 2, 2014, at 8:07 AM, Adam Barth wrote:
> On Tue, Jul 1, 2014 at 8:52 PM, Boris Zbarsky wrote:
>> On 7/1/14, 9:13 PM, Brendan Eich wrote:
>>> Are you sure? Because Gecko has used XBL (1) to implement, e.g., >> type=file>, or so my aging memory says.
>>
>> We use XBL to implement .
>
> I'
On Jul 2, 2014, at 3:57 AM, Brian Di Palma wrote:
> I'm happy to hear that it seems natural to trigger resource loading
> within a module.
>
>> For example, I could imagine adding a new syntax for loading an arbitrary
>> sub resource dependency.
>
> Absolutely. I think the platform could provi
On Jul 1, 2014, at 5:34 PM, Domenic Denicola
wrote:
> From: Edward O'Connor [mailto:eocon...@apple.com]
>
>>> But soft encapsulation is just as useless for explaining the platform
>>> as no encapsulation at all.
>>
>> I think "just as useless" overstates your case. Type 2 allows you to hide
On Jun 30, 2014, at 1:43 PM, Johannes Wilm wrote:
> On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa wrote:
>
>
> On Jun 26, 2014, at 3:24 PM, Olivier F wrote:
>
>> I agree these all seem the same. Here are a few other use cases I can think
>> of:
>>
&
On May 15, 2014, at 6:17 AM, Anne van Kesteren wrote:
> I'm still trying to grasp the philosophy behind shadow trees.
> Sometimes it's explained as "exposing the primitives" but the more I
> learn (rather slowly, this time at BlinkOn) the more it looks like a
> bunch of new primitives.
>
> We ca
I've talked to a few of my colleagues here at Apple who work on JavaScriptCore
but they don't seem to think that
the ES6 modules is the right mechanism to import arbitrary sub resource since
the semantics of loading CSS, HTML, etc...
depends on the context whereas ES6 module has exactly one purpo
On Jun 9, 2014, at 4:21 PM, Piotr Koszuliński
wrote:
> Responding to browser UI is one thing and I totally agree with the need for
> user intent events. If user shakes iPhone editor should be notified that user
> wanted to undo. But I does not tie this to commands at this point at all.
> Even
On Jun 23, 2014, at 8:23 AM, Robin Berjon wrote:
> On 06/06/2014 18:52 , Ryosuke Niwa wrote:
>> On Jun 6, 2014, at 6:40 AM, Robin Berjon wrote:
>>> On 05/06/2014 09:02 , Ryosuke Niwa wrote:
>>>> I agree visual selection of bidirectional text is a problem
>&g
On Jun 23, 2014, at 8:45 AM, Robin Berjon wrote:
> On 06/06/2014 19:13 , Ryosuke Niwa wrote:
>> On Jun 6, 2014, at 7:24 AM, Robin Berjon wrote:
>>> In order to handle them you have two basic options:
>>>
>>> a) Let the browser handle them for you (p
On Jun 30, 2014, at 4:19 PM, Ryosuke Niwa wrote:
>
> On Jun 24, 2014, at 3:44 AM, Robin Berjon wrote:
>
>> On 24/06/2014 00:38 , Ben Peters wrote:
>>>> Also, if the browser includes a "bold" command by default and I
>>>> don't suppor
On Jun 24, 2014, at 3:44 AM, Robin Berjon wrote:
> On 24/06/2014 00:38 , Ben Peters wrote:
>>> Also, if the browser includes a "bold" command by default and I
>>> don't support bolding and therefore cancel the event, the user who
>>> has been relying on the native UI is getting the worst possibl
On Jun 24, 2014, at 6:39 AM, Piotr Koszuliński
wrote:
>
> On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon wrote:
> On 23/06/2014 20:33 , Johannes Wilm wrote:
> I filed bugs on this on both Firefox and Chrome in spring 2013. It was
> briefly fixed in Chrome, but the fix was then retracted and w
On Jun 29, 2014, at 10:22 PM, Johannes Wilm wrote:
> Another use case: Create a track changes function within an editor (like
> https://github.com/NYTimes/ice ) that really should be run MVC in order to
> keep the code somewhat readable. Currently ICE breaks whenever any of the
> browser maker
> On Jun 22, 2014, at 9:19 PM, Julie Parent wrote:
>
>
>> On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa wrote:
>>
>>> On Jun 17, 2014, at 1:44 PM, Julie Parent wrote:
>>>
>>>
>>>> On Tue, Jun 17, 2014 at 12:22 PM, Olivier F
On Jun 17, 2014, at 9:00 AM, Piotr Koszuliński
wrote:
>
> On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent wrote:
> I certainly understand the concern that it would be impossible to properly
> catch and cancel all events.
>
> I'm not concerned only about this. I'm concerned about the fact that
On Jun 17, 2014, at 1:44 PM, Julie Parent wrote:
>
> On Tue, Jun 17, 2014 at 12:22 PM, Olivier F wrote:
> On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent wrote:
>
> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters wrote:
> On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent wrote:
> > If Intention even
On Jun 17, 2014, at 7:31 PM, Yoshifumi Inoue wrote:
> For overriding keyboard shortcut, how about exposing browser's key binding
> map as API rather than handling keyboard event?
> Example:
> window.keymap['Ctrl+B'] = function() { document.execCommand('back color'); }
I don't think this is a mu
On Jun 17, 2014, at 6:08 PM, Ben Peters wrote:
> Instead of execCommand, we could find another way to declare user intentions
> (shown in the image [1] upper right). To change a keyboard shortcut we could
> have a new property, say KeyboardEvent.intention. It could be initialized if
> a Comman
On Jun 12, 2014, at 5:07 PM, Olivier F wrote:
> I have been reading this and have a comment:
> http://w3c.github.io/editing-explainer/commands-explainer.html
>
> "Issue 11: We may not need contentEditable=minimal. The same thing can be
> accomplished by listening for commands and calling preve
It's probably a bug in WebKit/Blink. Since we're already throwing other
exceptions in some cases (e.g. INDEX_SIZE_ERR), we can probably change our
engine behavior.
yoshin: any opinions for blink?
On Jun 6, 2014, at 11:31 AM, Ben Peters wrote:
> I just filed this bug. Do we know of reasons why
On Jun 6, 2014, at 10:13 AM, Ryosuke Niwa wrote:
>
> On Jun 6, 2014, at 7:24 AM, Robin Berjon wrote:
>
>> On 05/06/2014 09:09 , Ryosuke Niwa wrote:
>>> On May 23, 2014, at 1:37 PM, Robin Berjon wrote:
>>>> Semantically, autocorrect and compos
On Jun 6, 2014, at 10:13 AM, Ryosuke Niwa wrote:
>
> On Jun 6, 2014, at 7:24 AM, Robin Berjon wrote:
>
>> On 05/06/2014 09:09 , Ryosuke Niwa wrote:
>>> On May 23, 2014, at 1:37 PM, Robin Berjon wrote:
>>>> Semantically, autocorrect and compos
On Jun 6, 2014, at 9:52 AM, Ryosuke Niwa wrote:
> On Jun 6, 2014, at 6:40 AM, Robin Berjon wrote:
>> On 05/06/2014 09:02 , Ryosuke Niwa wrote:
>>> I agree visual selection of bidirectional text is a problem worth
>>> solving but I don't think adding a generic m
On Jun 6, 2014, at 7:24 AM, Robin Berjon wrote:
> On 05/06/2014 09:09 , Ryosuke Niwa wrote:
>> On May 23, 2014, at 1:37 PM, Robin Berjon wrote:
>>> Semantically, autocorrect and compositing really are the same
>>> thing.
>>
>> They are not. Word substa
On May 26, 2014, at 1:25 AM, Anne van Kesteren wrote:
> On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote:
>> To implement text composition with this, I would like to have "wave
>> underline", "dotted underline", "thick underline" etc.
>
> Range.prototype.style seems complex in the context
On May 29, 2014, at 3:50 PM, Julie Parent wrote:
> Without default text input, the current proposal for
> contentEditable="minimal" is essentially just enabling cursors (drawing them,
> dispatching events, performing default actions). Rather than calling the
> mode "minimal", which is ill-def
On Jun 6, 2014, at 6:40 AM, Robin Berjon wrote:
> On 05/06/2014 09:02 , Ryosuke Niwa wrote:
>> I agree visual selection of bidirectional text is a problem worth
>> solving but I don't think adding a generic multi-range selection
>> support to the degree Gecko does is th
On Jun 6, 2014, at 6:27 AM, Robin Berjon wrote:
> On 28/05/2014 01:39 , Julie Parent wrote:
>> The discussion of which minimal default handling to include with
>> contenteditable="minimal" makes me wonder if contentEditable="minimal"
>> is necessary at all. It quickly becomes a can of worms of
On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
wrote:
> 1. That we need any native UI related to cE at all.
> We don't. We can display our own toolbars, with our own buttons, with our own
> icons and implementing our own logic. So the easiest solution to the problem
> with irrelevant native UI i
On Jun 6, 2014, at 7:30 AM, Robin Berjon wrote:
> On 06/06/2014 13:29 , Piotr Koszuliński wrote:
>> 1. That we need any native UI related to cE at all.
>> We don't. We can display our own toolbars, with our own buttons, with
>> our own icons and implementing our own logic. So the easiest solutio
On Jun 5, 2014, at 10:42 AM, Ben Peters wrote:
>> From: Ryosuke Niwa [mailto:rn...@apple.com]
>>
>> Can this be an attribute on elements instead? Otherwise, browsers would
>> have to repeatedly call these functions to update edit menu, etc...
>
> This may be an
On May 27, 2014, at 2:56 AM, Robin Berjon wrote:
> On 27/05/2014 09:19 , Piotr Koszuliński wrote:
>> Yes, it should be possible to disable whichever feature you don't need.
>> In some cases you don't need lists (because e.g. you're editing a text
>> that will become a content of a paragraph). An
Can this be an attribute on elements instead? Otherwise, browsers would have
to repeatedly call these functions to update edit menu, etc...
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're
On May 23, 2014, at 1:37 PM, Robin Berjon wrote:
> On 23/05/2014 21:32 , Jonas Sicking wrote:
>> On Fri, May 23, 2014 at 4:43 AM, Robin Berjon wrote:
>>> On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can probably be hand
On May 27, 2014, at 1:33 AM, Robin Berjon wrote:
> On 27/05/2014 01:47 , Ben Peters wrote:
>>> -Original Message- From: Robin Berjon
>>> On 26/05/2014 05:43 , Norbert Lindenberg wrote:
Were any speakers of bidirectional languages in the room when
this was discussed?
>>>
>>> I
On May 22, 2014, at 1:52 AM, Jonas Sicking wrote:
> On Thu, May 1, 2014 at 5:31 PM, Ben Peters wrote:
>> Proposal
>> To make this simpler for sites, frameworks, and browsers, it makes sense to
>> enable a new, simpler version of contentEditable that provides basic
>> functionality only. For th
Monday, May 5, 2014 11:28 PM
> To: Ryosuke Niwa; public-webapps@w3.org
> Subject: [selection] Selection.setBaseAndExtent
>
> I noticed that some websites use selection.setBaseAndExtent [1]. According to
> what limited documentation I could find, it works similar to
> selection
I agree it's better to let authors define what behavior they want from UA
instead of defining the set of behaviors ourselves.
Furthermore, I'd argue that we should separately have a mode where scripts
would get intention events but UA wouldn't enact any builtin editing commands
as default actio
> On May 13, 2014, at 2:37 AM, Anne van Kesteren wrote:
>
>> On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa wrote:
>> But expandos are usually added to HTMLElement and other builtin elements,
>> right?
>
> Depends, might be on instances too.
Sure, authors can
On May 12, 2014, at 2:00 AM, Anne van Kesteren wrote:
> On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
>> On the other hand, if the same element had exposed contentEditable property,
>> then UA's native contentEditable property would simply be overridden since
>&
> On May 9, 2014, at 3:22 AM, Anne van Kesteren wrote:
>
>> On Thu, May 8, 2014 at 6:49 PM, Brian Kardell wrote:
>> What do the parsing rules say about what an attr may begin with? Is it
>> plausible to just leading underscore or leading dash them as in CSS so that
>> all that's really necessar
On May 7, 2014, at 4:30 PM, Glenn Maynard wrote:
> On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa wrote:
> There is a difference in people not caring about forward compatibility and
> polluting the global namespace, and not providing a mechanism to do it right
> in the first place.
so in a forward compatible manner.
- R. Niwa
> On May 7, 2014, at 1:23 PM, Ian Hickson wrote:
>
>> On Wed, 7 May 2014, Ryosuke Niwa wrote:
>>
>> How are you going to quantify the risk of adding a new global attribute
>> in the future?
>
> Same we we do
On May 7, 2014, at 12:03 PM, Ian Hickson wrote:
> On Wed, 7 May 2014, Anne van Kesteren wrote:
>> On Tue, May 6, 2014 at 7:19 PM, Wilson Page wrote:
>>> I'm unsure whether or not it is safe to use custom attributes without
>>> the 'data-', I've heard mixed opinions. How do we know that chosen
I guess I wasn't paying attention when this came up during F2F but I probably
wouldn't be able to participate in regular conference calls due to time
constraints.
I'm not, however, opposed to others having such conference calls as long as
minutes/summary of discussions are posted on the mailing
On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov wrote:
> BTW, here's a jsbin that implements yield/transclude using existing Shadow
> DOM plumbing:
>
> http://jsbin.com/pacim/1/edit
Thanks for an example. That indeed polyfills the API we're proposing in terms
of the currently spec'ed API.
On
On Apr 22, 2014, at 10:13 AM, Dimitri Glazkov wrote:
> On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa wrote:
> Review: Template Inheritance in the Current Specification
>
> In the current specification, a super class doesn't define any hooks for
> subclasses. Instead,
On Apr 22, 2014, at 10:22 AM, Dimitri Glazkov wrote:
>
>
>
> On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa wrote:
> Review: Template Inheritance in the Current Specification
>
> In the current specification, a super class doesn't define any hooks for
> sub
On Apr 21, 2014, at 4:36 PM, William Chen wrote:
> On 4/17/14, 2:42 AM, Ryosuke Niwa wrote:
>> Review: Template Inheritance in the Current Specification
>>
>> In the current specification, a super class doesn't define any hooks for
>> subclasses. Instead,
ebkit.org
>
>
> doesn't make sense here. That would be equivalent with a "".
>
> Does it have any affect for your proposal?
>
>
>
>> On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa wrote:
>> Sorry, I forgot to add [Shadow DOM] in the title
> On Apr 13, 2014, at 5:21 AM, Aryeh Gregor wrote:
>
>> On Fri, Apr 11, 2014 at 9:05 PM, Ryosuke Niwa wrote:
>> Thanks for the pointer.
>>
>> Unfortunately, we might need to take a slightly different approach more
>> based on the CSS box tree because white
> On Apr 11, 2014, at 9:29 PM, Boris Zbarsky wrote:
>
>> On 4/11/14 10:09 AM, Domenic Denicola wrote:
>> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145
>> -
>> https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html
>
> The outcome of that was basical
On Apr 11, 2014, at 7:09 AM, Domenic Denicola
wrote:
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>
>> Given defining innerText is completely outside the scope of the selection
>> API specification, we might need to defer this part to a level 2
>> specification si
Done: http://rniwa.github.io/selection-api.html
On Apr 11, 2014, at 7:35 AM, Arthur Barstow wrote:
> On 4/10/14 11:41 PM, ext Ryosuke Niwa wrote:
>> I've uploaded the first cut the selection API specification unofficial draft
>> at https://github.com/rniwa/selection-ap
to
import those into web-platfrom-tests repository on github, and modernize them
as needed.
- R. Niwa
On Mar 13, 2014, at 4:43 PM, Ryosuke Niwa wrote:
> Hi,
>
> It appears that there is a lot of new features such as CSS regions and shadow
> DOM that have significant implications
On Apr 9, 2014, at 1:58 PM, Ryosuke Niwa wrote:
> On Apr 7, 2014, at 3:37 PM, Ben Peters wrote:
>
>>>>>> After working with developers inside and outside Microsoft, it seems
>>>>>> there are several types of paste that make sense in various scen
On Apr 7, 2014, at 3:37 PM, Ben Peters wrote:
> After working with developers inside and outside Microsoft, it seems
> there are several types of paste that make sense in various scenarios.
> For instance,
> 1- if pasting into a rich document, it could be important to maintain
On Apr 8, 2014, at 2:22 PM, Hallvord R. M. Steen wrote:
>> short status, plans, expectations and such for your spec(s).
>
> Some details are still being discussed with implementors (special thanks to
> Ben Peters at Microsoft for bringing up issues recently). In particular, it's
> still somewha
On Apr 2, 2014, at 3:50 AM, Arthur Barstow wrote:
> Hi All,
>
> The [Agenda] page for the April 10-11 meeting includes a list of Potential
> Topics and other than a meeting with some members of SysApps on April 10 to
> discuss the Service Worker and Manifest specs, currently, all other time
Sounds like a great plan to me. I'm not sure automatically forwarding emails to
public-webapps is a great fallback. It might be spammy for us. I think an
auto-reply with references to testing infra. mailing list would be better.
- R. Niwa
> On Apr 2, 2014, at 5:39 AM, Arthur Barstow wrote:
>
This is great! Thanks for writing this up.
Is it possible to have references to relevant mailing list and Bugzilla
discussions?
While summarizing the discussion so great, having hyperlinks to relevant email
threads will help bootstrap newcomers get up to speed if they wanted to give
feedback o
> On Mar 31, 2014, at 8:20 PM, Ondřej Žára wrote:
>
> Hi,
>
> let me introduce my Custom Element scenario: an interactive map element,
> powered by one of the well-known JS APIs (such as Google Maps API or so).
>
> Typically, the markup will be like
>
>
>
> However, the underlying JS needs
On Mar 27, 2014, at 3:27 AM, Arthur Barstow wrote:
> On 3/26/14 11:22 PM, ext Ryosuke Niwa wrote:
>> I just realized that the registration page links to
>> https://www.w3.org/2002/09/wbs/42538/WebApps-April2004-f2f/.
>>
>> Could you update it?
>
> That'
I just realized that the registration page links to
https://www.w3.org/2002/09/wbs/42538/WebApps-April2004-f2f/.
Could you update it?
- R. Niwa
On Mar 14, 2014, at 4:16 AM, Arthur Barstow wrote:
> Original Message
> Subject: [admin] Please register for WebApps 10-11 Apr
Maybe the problem comes from not distinguishing elements being created and
ready for API access versus elements is ready for interactions?
I’d also imagine that the exact appearance of a custom element between the time
the element is created and the time it is ready for interaction will depend o
> On Mar 18, 2014, at 2:22 PM, Johannes Wilm wrote:
>
>
>
>
>> On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon wrote:
>>> On 15/03/2014 18:44 , Johannes Wilm wrote:
>>> yes btw -- where should one go to lobby in favor of the editing spec? I
>>> have been communicating with several other browse
On Mar 17, 2014, at 4:59 AM, Robin Berjon wrote:
> On 15/03/2014 18:44 , Johannes Wilm wrote:
>> yes btw -- where should one go to lobby in favor of the editing spec? I
>> have been communicating with several other browser-based editor
>> projects, and there seems to be a general interest of more
On Mar 14, 2014, at 5:58 AM, Arthur Barstow wrote:
> On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote:
>> Hi,
>>
>> It appears that there is a lot of new features such as CSS regions and
>> shadow DOM that have significant implications on selection API, and we
>>
On Mar 13, 2014, at 5:08 PM, Domenic Denicola
wrote:
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>
>> Any thoughts and opinions?
>
> Have there been indications from vendors that they would have more resources
> to devote to implementing or critiquing the selection AP
Hi,
It appears that there is a lot of new features such as CSS regions and shadow
DOM that have significant implications on selection API, and we really need a
spec. for selection API these specifications can refer to.
Thankfully, Aryeh has done a great work writing the spec. for selection API
On Feb 12, 2014, at 11:23 AM, Rafael Weinstein wrote:
> I pushed the Web Components folks about exactly this issue (why aren't these
> callbacks just MutationObservers?) early last year. They convinced me (and I
> remain convinced) that these signals should be Custom Element callbacks and
> n
Sounds great to me.
On Feb 26, 2014, at 6:43 AM, Arthur Barstow wrote:
> Hi Robin, Dimitri, All,
>
> Since HTML Templates is now part of HTML5, to help avoid confusion, I think
> WebApps' last TR of the spec ([html-templates]) should be replaced with a WG
> Note that clearly indicates WebApps
On Feb 21, 2014, at 2:12 PM, Edward O'Connor wrote:
> Ryosuke wrote:
>
>> What if we added "formparticipant" boolean content attribute and fired
>> "formdata" event during form submission to serialize data?
>>
>> This way, we can add more events like "validate" to support more
>> features of bui
On Feb 20, 2014, at 2:39 PM, Jonas Sicking wrote:
> On Thu, Feb 20, 2014 at 2:09 PM, Edward O'Connor wrote:
>> +public-webapps, -www-tag in replies to avoid cross-posting
>>
>> Hi,
>>
>> Domenic wrote, to www-tag:
>>
>>> [C]an shadow DOM be used to explain existing elements, like or
>>> , i
On Feb 20, 2014, at 2:51 PM, Edward O'Connor wrote:
>> We could even make the built-in form controls like and
>> have a .formData() function which returns data in whatever
>> format we decide is the right one.
>
> Right. toFormData() or the like, parallel to toJSON().
Do we really want a gette
On Feb 20, 2014, at 6:29 PM, Hajime Morrita wrote:
> Firefox has already shipped
On Feb 18, 2014, at 10:35 AM, Dimitri Glazkov wrote:
> On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking wrote:
>
> What I mean is that for nodes that doesn't have a constructor, and
> whose parent doesn't have a constructor, no need to add them to the
> above arrays. Just insert them into their pa
> On Feb 16, 2014, at 1:21 AM, Alex Russell wrote:
>
>> On Sun, Feb 16, 2014 at 12:52 AM, Ryosuke Niwa wrote:
>>> On Feb 16, 2014, at 12:42 AM, Ryosuke Niwa wrote:
>>>
>>>> On Feb 15, 2014, at 11:30 PM, Alex Russell wrote:
>>>>
>
> On Feb 15, 2014, at 4:57 PM, Ryosuke Niwa wrote:
>
> Hi all,
>
> I’d like to propose one solution for
>
> [Shadow]: Specify imperative API for node distribution
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
>
> because select content attribut
On Feb 16, 2014, at 12:42 AM, Ryosuke Niwa wrote:
> On Feb 15, 2014, at 11:30 PM, Alex Russell wrote:
>
>> On Sat, Feb 15, 2014 at 4:57 PM, Ryosuke Niwa wrote:
>> Hi all,
>>
>> I’d like to propose one solution for
>>
>> [Shadow]: Specify imp
201 - 300 of 563 matches
Mail list logo
