On Tue, 08 May 2012 07:00:41 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 May 2012, Dimitri Glazkov wrote:
If you look at the two alternatives, one (the is attribute) asks the
authors to make the right choice. The other asks the component
developers to make the right choice. In the
I think it would be reasonable to defer the feature requested in 15210 to a
future version of Web Sockets API. It would also be reasonable to include it if
anyone feels strongly. Was a reason cited for why 15210 should be considered
critical? I could not find one in the minutes.
Cheers,
On Tue, May 8, 2012 at 9:48 AM, Charles McCathieNevile cha...@opera.com wrote:
There will certainly be people who don't care about accessibility and don't
do anything at all (just as there are for simple things like alt
attributes), and others who care but get it wrong, but aligning with the
On Tue, 08 May 2012 10:11:03 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, May 8, 2012 at 9:48 AM, Charles McCathieNevile
cha...@opera.com wrote:
There will certainly be people who don't care about accessibility and
don't do anything at all (just as there are for simple things
On 5/8/12 3:56 AM, ext Maciej Stachowiak wrote:
I think it would be reasonable to defer the feature requested in 15210 to a
future version of Web Sockets API. It would also be reasonable to include it if
anyone feels strongly. Was a reason cited for why 15210 should be considered
critical? I
On Tue, May 8, 2012 at 1:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
For the same reason that jQuery plugins are authored by a
significantly smaller set of people than jQuery users.
Significantly smaller, but not necessarily significantly more capable.
*Theoretically*, every jQuery
On Tue, May 8, 2012 at 2:33 PM, Scott González scott.gonza...@gmail.com wrote:
Accessibility is hard.
What makes it hard here is that you have to implement everything from
scratch. You have to implement keyboard support, mapping to the
accessibility API (WAI-ARIA), etc. Given that those code
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
Eliot Graff eliot...@microsoft.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
As discussed during last week's f2f meeting [Mins], IDB bug 14404 was
the last remaining bug blocking a LCWD of the spec and the other
remaining bugs are considered editorial and not blockers for LCWD
[Bugz]. Bug 1404 is now closed so this is a Call for Consensus to
publish a LCWD of IDB using
On Tue, May 8, 2012 at 5:49 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 8, 2012 at 2:33 PM, Scott González scott.gonza...@gmail.com
wrote:
Accessibility is hard.
What makes it hard here is that you have to implement everything from
scratch. You have to implement keyboard
WebApps has been asked to review and submit comments for two LCWDs by
the Web Performance WG:
1. Performance Timeline
http://www.w3.org/TR/2012/WD-performance-timeline-20120508/. This new
LCWD version takes into account the High Resolution Time specification,
removes string constants
I approve!!
/ Jonas
On Tue, May 8, 2012 at 8:29 AM, Arthur Barstow art.bars...@nokia.com wrote:
As discussed during last week's f2f meeting [Mins], IDB bug 14404 was the
last remaining bug blocking a LCWD of the spec and the other remaining bugs
are considered editorial and not blockers for
On 5/8/12 1:11 PM, ext Arthur Barstow wrote:
Greg, Tantek, All - I think there is an error in this part of the draft
Web Intents minutes:
[[
http://www.w3.org/2012/05/01-webapps-minutes.html#item06
tantek:do you know about opendoc and ola?
... systems for applications doing this. Have you
Art is correct. I'll incorporate that fix today when I prepare minutes.
- Original Message -
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, May 08, 2012 01:23 PM
To: public-webapps public-webapps@w3.org; Tantek Çelik
tan...@cs.stanford.edu; Greg Billock
Looks right to me.
On Tue, May 8, 2012 at 10:23 AM, Arthur Barstow art.bars...@nokia.com wrote:
On 5/8/12 1:11 PM, ext Arthur Barstow wrote:
Greg, Tantek, All - I think there is an error in this part of the draft Web
Intents minutes:
[[
All - assuming the 7 CfCs I started on May 2 to publish new FPWDs
passes, for each FPWD I will need to request a short-name as well as
provided a 1-liner description when the spec is published.
The short-name is the last part of the URI used in /TR/; f.ex. workers
is the short-name for Web
On Tue, May 8, 2012 at 9:10 PM, Arthur Barstow art.bars...@nokia.com wrote:
7. URL; http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
short-name = url
1-liner = Defines a URL API and related algorithms
Defines URL parsing, resolving, and canonicalizing as well as the URL
API is more
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16999
Summary: Clarify JS type for empty close reason
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
On Thu, 8 Sep 2011, Bryan Sullivan wrote:
OK, maybe I'm getting closer to understanding this. From your example,
when the event field is set, it's not a message event that is
dispatched but an event of type event name, so in order to see those
events, I need to use the addEventListener
The setTimeout comment in the w3 tracker is a pretty good reason. I
strongly agree with Olli Pettay's comment.
onemptybuffer would bring sockets in line with the server-side ondrain
event that we see in node.js and other socket APIs.
I disagree with Hixie's rationale that we need to give
On Thu, 8 Sep 2011, Glenn Maynard wrote:
Ian: Step 3 of [2] refers to the event type as the event name, and
step 4 refers to it as the type. This is confusing, since it looks
like it's referring to two different things. The DOM specs consistently
refer to it as type, consistent with the
Imagine you want to make a Web Component that draws a graph
Imagine that you'd like the graph to show more data if it's larger and less
if it's smaller. In other words, you don't want it to scale the data.
Imagine you set that component's size to width: 100%; height: 100% to scale
to its container
I think we've got request animation frame for the invisible content scenario.
For the height/width/resolution, CSS selectors and SVG are probably the easier
case.
Canvas however, that's not so easy.
-Charles
On May 8, 2012, at 5:30 PM, Gregg Tavares (勤) g...@google.com wrote:
Imagine you
On 5/8/12 8:30 PM, Gregg Tavares (勤) wrote:
AFAICT the resize event only fires on window.
There have been proposals over the years to change that.
Imagine a relatively heavy to repaint WebComponent like one that draws
an representation of an audio wave. If that component is hidden behind
We approve too!
Israel
On Tuesday, May 08, 2012 9:45 AM, Jonas Sicking wrote:
I approve!!
/ Jonas
On Tue, May 8, 2012 at 8:29 AM, Arthur Barstow art.bars...@nokia.com
wrote:
As discussed during last week's f2f meeting [Mins], IDB bug 14404 was
the last remaining bug blocking a LCWD
* Anne van Kesteren wrote:
I don't think that's really the argument. The argument is about
whether the long tail is going to be accessible (even if only a little
bit) or not at all.
That is, do we get
select is=restricted-color-pickeroption value=Redoption
value=Blue/select
styled as a
On Tue, May 8, 2012 at 5:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/8/12 8:30 PM, Gregg Tavares (勤) wrote:
AFAICT the resize event only fires on window.
There have been proposals over the years to change that.
Imagine a relatively heavy to repaint WebComponent like one that draws
On 5/9/12 1:20 AM, Gregg Tavares (勤) wrote:
I don't think I understand how requestAnimationFrame would work here.
Maybe my example was poor. I'm not suggesting a live constantly updating
audio wave. Instead I'm suggesting a static WebComponent that is heavy
to render. For example the wave
28 matches
Mail list logo
