On Dec 5, 2013, at 10:58 PM, Boris Zbarsky wrote:
> On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
>> Then how do we define a custom element using ES6 classes? Are we going to
>> not call the constructor?
>
> An excellent question, indeed. I don't have a good answer for you.
It appears to me that we
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going to not
call the constructor?
An excellent question, indeed. I don't have a good answer for you.
If we do make elements subclassable (which it seems like we should), we
would presu
On Dec 5, 2013, at 10:44 PM, Boris Zbarsky wrote:
> On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
>> That sounds like an implementation detail of Blink/WebKit.
>
> It seems like a pretty fundamental restriction for all current HTML parsers.
> In particular, the HTML parsing algorithm has no provisi
I agree that it isn't trivial to inherit from a built-in element as if it
is an author-defined element.
My point was that mentioning relationship between HTMLElement and built-in
elements on WebIDL doesn't matter in this discussion and we should focus on
other reasoning.
On Fri, Dec 6, 2013 at 3:
On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
That sounds like an implementation detail of Blink/WebKit.
It seems like a pretty fundamental restriction for all current HTML
parsers. In particular, the HTML parsing algorithm has no provisions
for script mutating the DOM at random points in the alg
On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
> On inheritance around HTMLElement family, there seems to be a confusion
> between interface side inheritance and implementation side inheritance.
Right. Differentiating the two is very important.
> For Custom Elements, the inheritance is not
On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.
In WebIDL, interfaces of HTML elements have inherited only from HTMLElement
interface. This is fine just because it cares only about interface (API
signat
On Dec 5, 2013, at 9:30 PM, Dimitri Glazkov wrote:
> On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
>> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
>> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
>> > 3) The approach pollu
Hi all,
Since the last working draft in August, IME API editor's draft has been
changed
significantly with the result of discussions at TPAC 2013. The biggest
change
is that I split the previous spec into 2 parts, streamlined main part and
others, so the main part
which has been mostly agreed on
On Dec 5, 2013, at 9:23 PM, Dimitri Glazkov wrote:
> On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov wrote:
>> There were several threads around this in March/April, but the main gist is
>> that we can't allow running user code when the parser i
On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa wrote:
> Thanks.
>
> On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
>
> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
>
>> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov
>> wrote:
>> > 3) The approach pollutes global name space with construc
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov wrote:
>
> There were several threads around this in March/April, but the main gist
> is that we can't allow running user code when the parser is building the
> tree, and thus we would need to decou
On Friday, December 6, 2013 at 7:38 AM, Mitar wrote:
> Hi!
>
> OK. You are maybe right, it would be easier just to get an event when
> user invokes a search (through key combination or menu or whatever)
> and then leave to webpage to deal with that. Probably it is possible
> to reimplement sea
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov wrote:
> There were several threads around this in March/April, but the main gist is
> that we can't allow running user code when the parser is building the tree,
> and thus we would need to decouple the timing of the constructor being called
> from t
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
> > 3) The approach pollutes global name space with constructors. This had been
> > voiced many times as unacceptable by develo
There were several threads around this in March/April, but the main gist is
that we can't allow running user code when the parser is building the tree,
and thus we would need to decouple the timing of the constructor being
called from the [[Construct]] internal method to make constructors
workable.
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov
> wrote:
> > 3) The approach pollutes global name space with constructors. This had
> been voiced many times as unacceptable by developers.
> >
> > 4) How does build a custom element that uses as
On Dec 5, 2013, at 3:15 PM, Ian Hickson wrote:
> On Thu, 5 Dec 2013, Jonas Sicking wrote:
>>
>> I think both are issues. I.e. I think we have two separate use cases:
>>
>> 1. Enable using the built-in rendering of form controls, but style them
>> using author-supplied CSS.
>>
>> 2. Enable comp
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
> 3) The approach pollutes global name space with constructors. This had been
> voiced many times as unacceptable by developers.
>
> 4) How does build a custom element that uses as its base element?
> What about or any other HTML element?
>
On Dec 5, 2013, at 7:32 PM, Scott Miles wrote:
> >> We don't think decoupling custom elements and shadow DOM completely is
> >> useful given that most important and natural use cases of custom elements
> >> involve the use of shadow DOM.
>
> Separating concerns is always useful, especially when
>> We don't think decoupling custom elements and shadow DOM completely is
useful given that most important and natural use cases of custom elements
involve the use of shadow DOM.
Separating concerns is always useful, especially when it involves
contentious standards.
I also would like to point ou
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa wrote:
> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov wrote:
>> 1) It is not friendly to ES6 classes. In fact, you can't use class syntax
>> and this syntax together.
Okay, let the author define the constructor.
>> 3) The approach pollutes global name
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa wrote:
> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov wrote:
>> 2) It couples templates, shadow DOM, and custom elements in a way that's
>> highly opinionated and inflexible. Throughout this year, we've tried many
>> various ways to get this right, and
From: Jonas Sicking [mailto:jo...@sicking.cc]
> The tricky part is finding a set of pseudo elements that work across
> different UAs, and that give authors enough control that they can integrate
> the control with the look-and-feel of their website.
I am wondering if we put forward the followi
On Mon, 02 Dec 2013 11:42:30 -, Mounir Lamouri
wrote:
Hi,
I am not sure that telling the webpage what the user is currently trying
to search is a great idea. However, if a webpage wants its own "find in
page" UI I guess a simple solution would be to do something similar to
the Forms Vali
Hi,
Given that many important/natural use cases of custom elements involve shadow
DOM,
can we add a flag to auto-create shadow DOM for custom elements?
In particular, can we add "template" as the third argument to document.register
so that
when a custom element is "instantiated", the specified
Could someone point me to a discussion/reasoning behind why we're using
createdCallback as opposed to the constructor
as a way of instantiating a custom element?
It's so awkward to have a separate callback in the world where we have ES6
classes.
- R. Niwa
On Thu, Dec 5, 2013 at 3:15 PM, Ian Hickson wrote:
> On Thu, 5 Dec 2013, Jonas Sicking wrote:
>>
>> I think both are issues. I.e. I think we have two separate use cases:
>>
>> 1. Enable using the built-in rendering of form controls, but style them
>> using author-supplied CSS.
>>
>> 2. Enable comp
On Thu, 5 Dec 2013, Jonas Sicking wrote:
>
> I think both are issues. I.e. I think we have two separate use cases:
>
> 1. Enable using the built-in rendering of form controls, but style them
> using author-supplied CSS.
>
> 2. Enable completely replacing the rendering of form controls
>
> I thi
On Thu, Dec 5, 2013 at 7:38 AM, Boris Zbarsky wrote:
> On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
>>
>> As I understand it, people want to do:
>>
>>
>
> That's not the main issue being discussed right now, as far as I can tell.
> What's being discussed, I think, is that people want to do things like
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:49 AM, Ian Hickson wrote:
> > On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
> >>
> >> Let me understand the problem of styling/replacing builtin form
> >> controls.
> >>
> >> As I understand it, people want to do:
> >>
> >>
> >> Oakland
Hi!
OK. You are maybe right, it would be easier just to get an event when
user invokes a search (through key combination or menu or whatever)
and then leave to webpage to deal with that. Probably it is possible
to reimplement search with combination of ranges and extraction of
text on the page.
S
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23790
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24008
Bug ID: 24008
Summary: [Streams API] Partially decreasing
numBytesBeingReturned without calling next read()
Product: WebAppsWG
Version: unspecified
Hardware: PC
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23720
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23772
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23724
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23718
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23732
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23743
Takeshi Yoshino changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Dec 4, 2013, at 5:38 PM, Bjoern Hoehrmann wrote:
> * Ryosuke Niwa wrote:
>> Now we know that there has been an effort to decouple the various Web
>> Components
>> features and specifications, and the Custom Elements specification was going
>> to
>> the Last Call on its own.
>>
>> Unfortuna
On Dec 5, 2013, at 8:49 AM, Ian Hickson wrote:
> On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
>>
>> Let me understand the problem of styling/replacing builtin form controls.
>>
>> As I understand it, people want to do:
>>
>>
>> Oakland
>> San Francisco
>> San Jose
>> ...
>>
>> or
>>
>>
>> to h
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
>
> Let me understand the problem of styling/replacing builtin form controls.
>
> As I understand it, people want to do:
>
>
> Oakland
> San Francisco
> San Jose
> ...
>
> or
>
>
> to have a nice fallback when "is" / shadow DOM is not supported.
>
> W
On Dec 5, 2013, at 7:38 AM, Boris Zbarsky wrote:
> On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
>> As I understand it, people want to do:
>>
>>
>
> That's not the main issue being discussed right now, as far as I can tell.
Sorry, I should have been more explicit in my email but I intended to ask
s
I've been putting off a response on this, but I have some things to add...
The topic on this thread was originally HTML Imports - it seems like some
of the concerns expressed extend beyond imports and are a little wider
ranging. I am cross posting this comment to public-next...@w3.org as I
think i
Yeah, the big issues come in with using the existing elements. Given , we want to keep all of the semantics (the APIs, built-in
validation, etc.), but apply custom styling. Custom styling may come in the
form of CSS or it may come in the form of a completely new UI that uses JS.
The latter may or m
On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
That's not the main issue being discussed right now, as far as I can tell.
What's being discussed, I think, is that people want to do things like:
and then style the datepicker in some particular way.
-Boris
On Thu, Dec 5, 2013, at 2:08, Mitar wrote:
> But I agree, that requires some more changes. For example, currently
> it is not really possible to style how found elements are highlighted.
> And it is not possible for page to say to UA to retry searching
> because the document has modified. I believe
On Thu, Dec 5, 2013, at 6:06, Jonas Sicking wrote:
> On Dec 4, 2013 6:20 AM, "Henri Sivonen" wrote:
> > >
> >
> > Are manifests really short enough for this kind of thing?
>
> For single-page apps I would imagine it will be quite simple yes. Not
> quite
> as short as the above, but will reasonab
* Arthur Barstow wrote:
>Subject: [process] Process Violation with Custom Elements LC?
>Björn,
I am not the right person to contact if you think there may have been
procedural problems with a recommendation track transition.
I cannot recommend anyone to contact either.
I am sorry.
--
Björn Höh
On 12/4/13 3:53 PM, ext Marcos Caceres wrote:
On Thursday, December 5, 2013 at 3:57 AM, Arthur Barstow wrote:
Thanks for the update Feras.
Re getting `wide review` of the latest [ED], which groups, lists and
individuals should be asked to review the spec?
In IRC just now, jgraham mention
On 12/4/13 8:38 PM, ext Bjoern Hoehrmann wrote:
* Ryosuke Niwa wrote:
Now we know that there has been an effort to decouple the various Web Components
features and specifications, and the Custom Elements specification was going to
the Last Call on its own.
Unfortunately, we didn't know about th
>> 1) Sync APIs are inherently easier to use than async ones, and they are much
>> less error prone. JS developers are not C++ developers. Whenever possible,
>> it's
>> just better to make things more simpler and convenient.
>
>This argument is not particularly helpful. Apart from that, many JS AP
On Wed, 04 Dec 2013 18:58:10 +0100, Scott Miles wrote:
seems a specification that seems really pushed/rushed
Since my team (Polymer) has been working with imports in practice for a
year-and-a-half (100% public and open-source, btw) this seems a strange
conclusion.
As Bjoern pointed out, thi
Hi,
Let me understand the problem of styling/replacing builtin form controls.
As I understand it, people want to do:
Oakland
San Francisco
San Jose
...
or
to have a nice fallback when "is" / shadow DOM is not supported.
Why can't we just do:
Oakland
San Francisco
San Jose
...
and
ins
I am not especially connnected to MediaStream/ WebRTC, so probably it's
more efficient if Rob/Arthur do it.
I forward it to WebCrypto.
Right now there is still a list of bugs but regarding the current
edition I would comment what I already said separately to Takeshi/Feras:
I am not very convi
I totally agree, this is the kind of things I said several weeks ago
about why we shouldn't promote the development of sync APIs on
workers, and stick only with the same async APIs from the main thread.
2013/12/5 Charles Pritchard :
>
> On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:
>>
>> IMHO, we should
57 matches
Mail list logo
