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 ch...@jumis.com:
On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:
IMHO,
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
Hi,
Let me understand the problem of styling/replacing builtin form controls.
As I understand it, people want to do:
select name=cities is=map
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
or
input is=switch type=checkbox ...
to have a nice fallback when is
On Wed, 04 Dec 2013 18:58:10 +0100, Scott Miles sjmi...@google.com 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
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 APIs
use
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
On Thu, Dec 5, 2013, at 6:06, Jonas Sicking wrote:
On Dec 4, 2013 6:20 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
meta name=manifest content='{
a: 1,
b: foopy
}'
Are manifests really short enough for this kind of thing?
For single-page apps I would imagine it will be quite
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 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
select name=cities is=map
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:
input type=date
and then style the
Yeah, the big issues come in with using the existing elements. Given input
type=date, 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
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
On Dec 5, 2013, at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
select name=cities is=map
That's not the main issue being discussed right now, as far as I can tell.
Sorry, I should have been more explicit in
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:
select name=cities is=map
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
or
input is=switch
On Dec 4, 2013, at 5:38 PM, Bjoern Hoehrmann derhoe...@gmx.net 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.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23743
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23732
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23718
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23724
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23772
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23720
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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=23790
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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.
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch 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:
select name=cities
On Thu, Dec 5, 2013 at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
select name=cities is=map
That's not the main issue being discussed right now, as far as I can tell.
What's being discussed, I think, is that
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 think 1 is
On Thu, Dec 5, 2013 at 3:15 PM, Ian Hickson i...@hixie.ch 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
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
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
On Mon, 02 Dec 2013 11:42:30 -, Mounir Lamouri mou...@lamouri.fr
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
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 following
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org 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
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org 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
On Dec 5, 2013, at 7:32 PM, Scott Miles sjmi...@google.com 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,
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org 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 name-card as its base element?
What about div
On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch 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
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org
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
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
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
3) The approach pollutes global name space with constructors. This had
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org 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
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org 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,
On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa rn...@apple.com wrote:
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org
On Dec 5, 2013, at 9:23 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist is
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 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
On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com 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
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
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
On Dec 5, 2013, at 10:44 PM, Boris Zbarsky bzbar...@mit.edu 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
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu 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
50 matches
Mail list logo
