[Component Model]: Decorators and Fallback Content
TL;DR: How about supporting appearance: none for the canvas element,
and decorator as well.
The component introduces a decorator: url(#url) semantic to upgrade
elements while maintaining backward compatibilty.
Decorators can be applied in various manner, but this is where I'd like
to focus:
button is=x-my-componentThis is a button/button
For a browser that does not support decorators, or if the decorator is
unavailable, that's going to turn into a standard button.
Great stuff. If the decorator is supported, we've got ourselves whatever
it is the component author intended. Good stuff.
Now let's take a look at Canvas components:
canvasbuttonThis is a button/button/canvas
This is no fun, how do I reach that fallback content, visually? There
are many means of doing it, but it's not as clean as I'd like.
And now a trip down memory lane. It was about five years ago I was
actively developing a form-centric application, it uses mouseover to
change the background color of some input buttons. I look silly now, now
that submit buttons can be styled by the user agent.
So, back to the future, I ought to add input[type=submit] {
-webkit-appearance: none; } to my old project, for a quick fix.
If you're with me so still, I've just ensured that the present Webkit,
let's say Chrome, for this example, will now render my input submit
buttons as defined in CSS, and not in the manner inherited by the
operating system. That's important for my mouse events, because the OS
rendered button is very different than the button that displays when CSS
is handling the task. If you have questions about this, ask, and I'm
sure we can hunt down some examples together.
And that takes me back to the canvas and decorator examples.
canvas style=-webkit-appearance: nonebuttonThis is a
button/button/canvas
That ought to go ahead and hide the Canvas element and show the button
element, as though Canvas were not supported. It shouldn't nuke the
Canvas context, but it should no longer be in the render tree. This
makes it easy to turn Canvas off and on, and to see that fallback
content. That's something I want in Canvas, and that's something I want
for decorators in the component model.
And since we're stuck with appearance: none, it seems like the right
semantic to pick up for this task. I think it's a good fit.
Also, CSS-UI doesn't want it -- and I think they're right in booting it
out. So I'm proposing that the Component Model pick it up.
-Charles
[Bug 15096] New: 1.function supports_html5_storage() { 2. try { 3. return 'localStorage' in window window['localStorage'] !== null; 4. } catch (e) { 5. return fals
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15096
Summary: 1.function supports_html5_storage() {2.try {
3.return 'localStorage' in window
window['localStorage'] !== null;4.} catch (e)
{5.return false;6.}7.}
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org
Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top
Comment:
1.function supports_html5_storage() {
2.try {
3. return 'localStorage' in window window['localStorage'] !== null;
4.} catch (e) {
5. return false;
6.}
7.}
Posted from: 112.65.138.138
User agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.0.4506.2152; .NET CLR
3.5.30729; .NET CLR 1.1.4322)
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 15097] New: function supports_html5_storage() { try { return 'localStorage' in window window['localStorage'] !== null; } catch (e) { return false;
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15097
Summary: function supports_html5_storage() {try {
return 'localStorage' in window
window['localStorage'] !== null;} catch (e) {
return false;}}
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org
Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top
Comment:
function supports_html5_storage() {
try {
return 'localStorage' in window window['localStorage'] !== null;
} catch (e) {
return false;
}
}
Posted from: 112.65.138.138
User agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.0.4506.2152; .NET CLR
3.5.30729; .NET CLR 1.1.4322)
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: Standards for Web applications on mobile devices: November 2011 updates
Le mercredi 07 décembre 2011 à 00:01 +, Marcos Caceres a écrit : Although I think this document is quite informative, I again would like to raise objections about lumping app cache and widgets together for the same reasons I raised last time. Your last message on the thread last time made me think your objections had been lifted: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1459.html But I guess I misunderstood it. I'm a bit at loss as to how to make progress on this. However, I don't want to have that argument again: I just want to say I think it's disingenuous (perhaps make it more clear at the top of the document that the document represents mostly your personal opinion?). I'm also concerned that the text that I contributed to the document about the variety of applicability of the technologies has been removed. I did remove it, indeed; listing all the things the document doesn't do didn't seem very helpful to the reader, and seemed redundant with the scoping statement of the document: This document summarizes the various technologies developed in W3C that increase the power of Web applications, and how they apply more specifically to the mobile context. I'm also concerned at use of the terms limited and very limited to label current implementations as being both subjective and relativistic - and it implies that attempts to implement have ceased; particularly next to well deployed, Largely deployed, Growing, and Getting deployed. Either remove that column, or present some data to which you can underpin each of the labels. I agree that the current data are somewhat subjective (and have amended the description of the column in the introduction accordingly). My sources have been: * my personal knowledge of what's available where, and what I've heard is coming soon * http://mobilehtml5.org/ * caniuse.com Ideally, I would like a lot more of the data in that column to come from W3C test suite results, but since we're not there yet, I think subjective (but I'm hoping reasonably well informed) data are probably more helpful to the reader than no data at all. And as any other part of the document, I'm happy to get specific feedback on which of these assessments you think are not in line with the market. Dom
[Bug 15096] 1.function supports_html5_storage() { 2. try { 3. return 'localStorage' in window window['localStorage'] !== null; 4. } catch (e) { 5. return false;
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15096 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ms2...@gmail.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: QSA, the problem with :scope, and naming
On 2011-10-20 10:14, Sean Hogan wrote: The primary use-case for matchesSelector() has been event-delegation, and this is the same for matches(). More specifically, consider the following scenario: jQuery adds a new event registration method that uses event delegation to mimic the behavior of: $(elem).find( div .thinger).bind(eventType, fn); The new method is called proxybind(), and the equivalent of the above is: $(elem).proxybind( div .thinger, eventType, fn); I cannot find any documentation for proxybind() and it doesn't seem to be in JQuery 1.7.1. I found a proxy() method, but it doesn't seem to match what you're talking about. http://api.jquery.com/jQuery.proxy/ Also, the JQuery.is() method, which is the method similar to .matchesSelector(), does not support any context node, and so it does not work with .is(.foo, context). Could you provide some documentation for, or at least a version of JQuery that implements proxybind? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Component Model]: Decorators and Fallback Content
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchard ch...@jumis.com wrote:
TL;DR: How about supporting appearance: none for the canvas element, and
decorator as well.
The component introduces a decorator: url(#url) semantic to upgrade
elements while maintaining backward compatibilty.
Decorators can be applied in various manner, but this is where I'd like to
focus:
button is=x-my-componentThis is a button/button
That's not a decorator. That's a custom element. They are very
different. Did I fail to draw enough distinction in the explainer?
For a browser that does not support decorators, or if the decorator is
unavailable, that's going to turn into a standard button.
Great stuff. If the decorator is supported, we've got ourselves whatever it
is the component author intended. Good stuff.
Yep, except s/decorator/custom element.
Now let's take a look at Canvas components:
What are Canvas components?
canvasbuttonThis is a button/button/canvas
This is no fun, how do I reach that fallback content, visually? There are
many means of doing it, but it's not as clean as I'd like.
Why would you need to reach there visually? I think I am lost.
And now a trip down memory lane. It was about five years ago I was actively
developing a form-centric application, it uses mouseover to change the
background color of some input buttons. I look silly now, now that submit
buttons can be styled by the user agent.
So, back to the future, I ought to add input[type=submit] {
-webkit-appearance: none; } to my old project, for a quick fix.
If you're with me so still, I've just ensured that the present Webkit, let's
say Chrome, for this example, will now render my input submit buttons as
defined in CSS, and not in the manner inherited by the operating system.
That's important for my mouse events, because the OS rendered button is very
different than the button that displays when CSS is handling the task. If
you have questions about this, ask, and I'm sure we can hunt down some
examples together.
And that takes me back to the canvas and decorator examples.
canvas style=-webkit-appearance: nonebuttonThis is a
button/button/canvas
That ought to go ahead and hide the Canvas element and show the button
element, as though Canvas were not supported. It shouldn't nuke the Canvas
context, but it should no longer be in the render tree. This makes it easy
to turn Canvas off and on, and to see that fallback content. That's
something I want in Canvas, and that's something I want for decorators in
the component model.
What are you trying to accomplish? Can we start with that first?
And since we're stuck with appearance: none, it seems like the right
semantic to pick up for this task. I think it's a good fit.
Also, CSS-UI doesn't want it -- and I think they're right in booting it out.
So I'm proposing that the Component Model pick it up.
-Charles
Re: [Component Model]: Decorators and Fallback Content
On 12/7/11 7:36 AM, Dimitri Glazkov wrote:
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchardch...@jumis.com wrote:
TL;DR: How about supporting appearance: none for thecanvas element, and
decorator as well.
The component introduces a decorator: url(#url) semantic to upgrade
elements while maintaining backward compatibilty.
Decorators can be applied in various manner, but this is where I'd like to
focus:
button is=x-my-componentThis is a button/button
That's not a decorator. That's a custom element. They are very
different. Did I fail to draw enough distinction in the explainer?
Sorry about the confusion. I did not make the clear distinction of
custom tags with templates and decorators.
Now let's take a look at Canvas components:
What are Canvas components?
A canvas element with usable fallback content.
This is not a component:
canvasYou do not have Canvas, you Shall not Pass!/canvas
This is a component:
canvas
legend tabindex=-1 for=buttonThe Big Red Button/legend
button tabindex=0 id=buttonLaunch Missiles/button
/canvas
canvasbuttonThis is a button/button/canvas
This is no fun, how do I reach that fallback content, visually? There are
many means of doing it, but it's not as clean as I'd like.
Why would you need to reach there visually? I think I am lost.
I've repeatedly had cases where I'd like to show the sub-tree. While I
can certainly do dom manipulation to accomplish it, in my experience, it
makes a lot more sense and is a lot easier to use css.
This is not solely about accessibility, though I do think supporting
appearance: none would help developers work with their sub-tree.
It's a frustrating practice to need to intentionally break the canvas
tag to debug in place:
not-canvasbutton data-notes=I am now debugging my sub-treeTap for
a treat/button/canvas
I don't want to get too wrapped up in providing use cases: if it's an
issue, I will being a more formal list in my next response. In general,
I'd say the use is for debugging and for simply showing a plain view. It
encourages authors to use semantic HTML appropriately.
The ability to switch presentational modes is important. It's what CSS
is all about, isn't it?
And now a trip down memory lane. It was about five years ago I was actively
developing a form-centric application, it uses mouseover to change the
background color of some input buttons. I look silly now, now that submit
buttons can be styled by the user agent.
So, back to the future, I ought to add input[type=submit] {
-webkit-appearance: none; } to my old project, for a quick fix.
If you're with me so still, I've just ensured that the present Webkit, let's
say Chrome, for this example, will now render my input submit buttons as
defined in CSS, and not in the manner inherited by the operating system.
That's important for my mouse events, because the OS rendered button is very
different than the button that displays when CSS is handling the task. If
you have questions about this, ask, and I'm sure we can hunt down some
examples together.
And that takes me back to thecanvas and decorator examples.
canvas style=-webkit-appearance: nonebuttonThis is a
button/button/canvas
That ought to go ahead and hide the Canvas element and show the button
element, as though Canvas were not supported. It shouldn't nuke the Canvas
context, but it should no longer be in the render tree. This makes it easy
to turn Canvas off and on, and to see that fallback content. That's
something I want in Canvas, and that's something I want for decorators in
the component model.
What are you trying to accomplish? Can we start with that first?
I want to disable these higher presentation layers via CSS.
That's what happens with: button style=-webkit-appearance: none /.
Custom decorations are dropped, and we go back into the past, a simpler
time.
I'd like to see appearance: none work with custom elements and canvas
elements.
It would benefit users, to be able to easily change the style sheet and
I believe it would benefit developers, to be able to more easily debug,
with dual-use of their markup.
I think this should apply to audio controls as well;
audio controlsa hrefMy Music File/a/audio
That'd hide the controls and simply show the link, as though audio were
not supported.
I've been trying for some time to find a semantic to fit this use I
have. CSS replaced content was not a good fit. appearance: none seems
to be the right one.
-Charles
Re: [Component Model]: Decorators and Fallback Content
On Wed, Dec 7, 2011 at 9:01 AM, Charles Pritchard ch...@jumis.com wrote:
On 12/7/11 7:36 AM, Dimitri Glazkov wrote:
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchardch...@jumis.com
wrote:
TL;DR: How about supporting appearance: none for thecanvas element,
and
decorator as well.
The component introduces a decorator: url(#url) semantic to upgrade
elements while maintaining backward compatibilty.
Decorators can be applied in various manner, but this is where I'd like
to
focus:
button is=x-my-componentThis is a button/button
That's not a decorator. That's a custom element. They are very
different. Did I fail to draw enough distinction in the explainer?
Sorry about the confusion. I did not make the clear distinction of custom
tags with templates and decorators.
Now let's take a look at Canvas components:
What are Canvas components?
A canvas element with usable fallback content.
This is not a component:
canvasYou do not have Canvas, you Shall not Pass!/canvas
This is a component:
canvas
legend tabindex=-1 for=buttonThe Big Red Button/legend
button tabindex=0 id=buttonLaunch Missiles/button
/canvas
Why is that a component? And why is there a canvas tag surrounding
it? I must have not been following some discussion somewhere. Is
canvas there to provide some presentational quality? If so, I would
write this like so using Web Components:
div is=x-foobar
legend ...
button ...
/div
Then the x-foobar custom element is defined as:
element name=x-foobar extends=div
script
//...
/script
template
canvas/canvas
/template
/element
In other words, put canvas in the shadow DOM, leave the meaningful
tags in the document.
canvasbuttonThis is a button/button/canvas
This is no fun, how do I reach that fallback content, visually? There are
many means of doing it, but it's not as clean as I'd like.
Why would you need to reach there visually? I think I am lost.
I've repeatedly had cases where I'd like to show the sub-tree. While I can
certainly do dom manipulation to accomplish it, in my experience, it makes a
lot more sense and is a lot easier to use css.
From my perspective, you're narrowing on a solution without first
stating a problem. Why do you need to show the subtree? Give me an
example? I am not trying to be a butt, just failing to understand what
you're trying to do.
This is not solely about accessibility, though I do think supporting
appearance: none would help developers work with their sub-tree.
To paraphrase the famous Princess Bride quote, I don't think
appearance: none means what you think it means. The effects of
-webkit-appearance are limited to painting. Extending it to mean
something else is probably going to be more pain than just adding a
new primitive. I am not sure if there's a need for a new primitive,
though.
It's a frustrating practice to need to intentionally break the canvas tag to
debug in place:
not-canvasbutton data-notes=I am now debugging my sub-treeTap for a
treat/button/canvas
I am still puzzled why you would want to stuff a live DOM tree into a
canvas, but it seems that the solution I outlined earlier should help
you here.
I don't want to get too wrapped up in providing use cases: if it's an issue,
I will being a more formal list in my next response. In general, I'd say the
use is for debugging and for simply showing a plain view. It encourages
authors to use semantic HTML appropriately.
The ability to switch presentational modes is important. It's what CSS is
all about, isn't it?
And now a trip down memory lane. It was about five years ago I was
actively
developing a form-centric application, it uses mouseover to change the
background color of some input buttons. I look silly now, now that submit
buttons can be styled by the user agent.
So, back to the future, I ought to add input[type=submit] {
-webkit-appearance: none; } to my old project, for a quick fix.
If you're with me so still, I've just ensured that the present Webkit,
let's
say Chrome, for this example, will now render my input submit buttons as
defined in CSS, and not in the manner inherited by the operating system.
That's important for my mouse events, because the OS rendered button is
very
different than the button that displays when CSS is handling the task.
If
you have questions about this, ask, and I'm sure we can hunt down some
examples together.
And that takes me back to thecanvas and decorator examples.
canvas style=-webkit-appearance: nonebuttonThis is a
button/button/canvas
That ought to go ahead and hide the Canvas element and show the button
element, as though Canvas were not supported. It shouldn't nuke the
Canvas
context, but it should no longer be in the render tree. This makes it
easy
to turn Canvas off and on, and to see that fallback content. That's
something I want in Canvas, and that's something I want for decorators in
the component model.
What are you trying to accomplish? Can we start
Re: Standards for Web applications on mobile devices: November 2011 updates
On Wednesday, 7 December 2011 at 09:51, Dominique Hazael-Massieux wrote: Le mercredi 07 décembre 2011 à 00:01 +, Marcos Caceres a écrit : Although I think this document is quite informative, I again would like to raise objections about lumping app cache and widgets together for the same reasons I raised last time. Your last message on the thread last time made me think your objections had been lifted: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1459.html But I guess I misunderstood it. I'm a bit at loss as to how to make progress on this. I was in agreement when the disclaimer I proposed was included in your document, because it said that this was just one (of many) application of the technology (particularly as it relates to widgets, which are used in a bunch of weird and wonderful places). Without that context, it sounds like widgets are somehow competing (and badly losing) with AppCache. That's my reading, and that's why I keep harping on about :) However, I don't want to have that argument again: I just want to say I think it's disingenuous (perhaps make it more clear at the top of the document that the document represents mostly your personal opinion?). I'm also concerned that the text that I contributed to the document about the variety of applicability of the technologies has been removed. I did remove it, indeed; listing all the things the document doesn't do didn't seem very helpful to the reader, and seemed redundant with the scoping statement of the document: This document summarizes the various technologies developed in W3C that increase the power of Web applications, and how they apply more specifically to the mobile context. Maybe I'm being too critical about this, but these technologies don't increase the power of anything: they are the bits and pieces applications to be created by humans - power of application comes from the brains that put these tools to work, not from the tools themselves. I'm also concerned at use of the terms limited and very limited to label current implementations as being both subjective and relativistic - and it implies that attempts to implement have ceased; particularly next to well deployed, Largely deployed, Growing, and Getting deployed. Either remove that column, or present some data to which you can underpin each of the labels. I agree that the current data are somewhat subjective (and have amended the description of the column in the introduction accordingly). My sources have been: * my personal knowledge of what's available where, and what I've heard is coming soon * http://mobilehtml5.org/ * caniuse.com (http://caniuse.com) Ideally, I would like a lot more of the data in that column to come from W3C test suite results, but since we're not there yet, I think subjective (but I'm hoping reasonably well informed) data are probably more helpful to the reader than no data at all. I don't think that data is all that suitable: for instance, I know of a lot of widget runtimes that implement the widget specs, but I don't include them in the implementation report because they are not fully conforming (and because those vendors have not asked to be included). I only include stuff that allows me to meet the exit criteria for a particular specification: it would be a lot of work for me (or anyone) to source that data by running an implementation through a test suite. And as any other part of the document, I'm happy to get specific feedback on which of these assessments you think are not in line with the market. I'm biased, so lets start with widgets. For instance, why would you say limited instead of growing? I guess that is only true if you exclusively look at the big Web Browsers. If that is the case, then that is a fair claim (no new web browsers have implemented the widget spec). However, other software has (e.g., a bunch of new WAC runtimes, PhoneGap, etc.). -- Marcos Caceres http://datadriven.com.au
Re: [Component Model]: Decorators and Fallback Content
On 12/7/2011 9:45 AM, Dimitri Glazkov wrote: On Wed, Dec 7, 2011 at 9:01 AM, Charles Pritchardch...@jumis.com wrote: On 12/7/11 7:36 AM, Dimitri Glazkov wrote: On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchardch...@jumis.com wrote: Now let's take a look at Canvas components: What are Canvas components? Acanvas element with usable fallback content. This is not a component: canvasYou do not have Canvas, you Shall not Pass!/canvas This is a component: canvas legend tabindex=-1 for=buttonThe Big Red Button/legend button tabindex=0 id=buttonLaunch Missiles/button /canvas Why is that a component? And why is there acanvas tag surrounding it? I must have not been following some discussion somewhere. Is canvas there to provide some presentational quality? If so, I would write this like so using Web Components: div is=x-foobar legend ... button ... /div Then the x-foobar custom element is defined as: element name=x-foobar extends=div script //... /script template canvas/canvas /template /element In other words, putcanvas in the shadow DOM, leave the meaningful tags in the document. I called it a component to try to avoid confusion. Didn't work! If you'd prefer, I'll call it an interactive canvas element or a canvas widget. And while I understand the nature of your suggestion, I'm talking about existing implementations. Yes, when the Component Model is available and implemented, we'll have another option to use with canvas based interactive widgets. It's been my position that the existing practices of the canvas element are a helpful topic in understanding the needs of Web Components. It's also my position that canvas should be heavily considered in the design of web components, and that web components should be heavily considered in future discussions about canvas. I intend to bring them up in public-canvas-api when Web Components is a little further along. Again, I apologize for the miscommunication here, I only intended to bring up a single issue, CSS appearance. canvasbuttonThis is a button/button/canvas This is no fun, how do I reach that fallback content, visually? There are many means of doing it, but it's not as clean as I'd like. Why would you need to reach there visually? I think I am lost. I've repeatedly had cases where I'd like to show the sub-tree. While I can certainly do dom manipulation to accomplish it, in my experience, it makes a lot more sense and is a lot easier to use css. From my perspective, you're narrowing on a solution without first stating a problem. Why do you need to show the subtree? Give me an example? I am not trying to be a butt, just failing to understand what you're trying to do. The problem is that it is a kludge to view alternate content. IE9 is the only browser that makes it easy on me, and it makes it easy because in their developer tools I can switch to IE8-mode, where Canvas was not supported. The other problem is that I would like to use CSS media selectors to show the fallback content, instead of the canvas painting, in some circumstances. While I can do a bunch of DOM mutations, it makes a lot more sense to have a pure-CSS option. Additionally, projects like NoScript do not show canvas fallback content. This would make it easier on the authors of Noscript to do so, via simple CSS. I'm trying to introduce an easy to use method for showing fallback content in advanced controls: in HTML5. HTML4 did not really have this issue. It was there, but not such a big deal. This is not solely about accessibility, though I do think supporting appearance: none would help developers work with their sub-tree. To paraphrase the famous Princess Bride quote, I don't think appearance: none means what you think it means. The effects of -webkit-appearance are limited to painting. Extending it to mean something else is probably going to be more pain than just adding a new primitive. I am not sure if there's a need for a new primitive, though. appearance: none, will affect the presentation as well as width and height of the element. It has similarities to the template proposal. While it's not so apparent on Windows, it's very apparent on OS X, with input type=submit. The semantic was created (I believe) prior to Canvas. It's not yet been applied. So I'm suggesting that we extend its meaning, because it's a close fit. This says, use the CSS I've put in the document and forget all that fancy upgrading of the element: input type=submit style=-webkit-appearance: none That seems an appropriate semantic for doing the same with canvas and audio controls. It's a frustrating practice to need to intentionally break the canvas tag to debug in place: not-canvasbutton data-notes=I am now debugging my sub-treeTap for a treat/button/canvas I am still puzzled why you would want to stuff a live DOM tree into a canvas, but it seems that the solution I outlined earlier should help you here. Putting live elements into
[Bug 13786] Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13786 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Ian 'Hixie' Hickson i...@hixie.ch 2011-12-07 18:26:34 UTC --- Done. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15104] New: In reply to: p class=warningFollowing HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSoc
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15104 Summary: In reply to: p class=warningFollowing HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenl Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: In reply to: p class=warningFollowing HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname./p It SHOULD be possible to get the information from HTTP Status Codes 4xx and 5xx, to provide the ability to return useful information to the client, for example, a 400 Bad Request response with the following message WebSocket Version 8 or greater is required. Posted from: 189.239.8.169 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com wrote: Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? I realized the other day that the question also applies to what should db.objectStoreNames return? It makes sense that whatever changes we make to .version we'd also make to .objectStoreNames. Do we revert it to the value it had before the transaction was started? Do we throw? Do we return null/0? Ultimately I feel like there really is very little reason for someone to use these properties if the VERSION_CHANGE transaction fails, and so I'm leaning more towards that we should do whatever is easy to implement. So what I suggest is that we do the same thing as for .close(). I.e. we leave the values untouched. This seems not only easy to implement but also is consistent with .close(). / Jonas What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name=assigned db name, version = 0, and objectStoresNames = null. Do you agree? Israel
RE: [indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler
On Saturday, December 03, 2011 9:28 PM, Jonas Sicking wrote: Subject: Re: [indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler On Thu, Dec 1, 2011 at 7:16 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, November 22, 2011 5:30 PM, Israel Hilerio wrote: Subject: [indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler What should be the value of the error attribute on the open request after a VERSION_CHANGE transaction is aborted? We're thinking it should be AbortError independent of whether the transaction is aborted programmatically or due to a system failure. Do you guys agree? Israel Should I take the silence to mean we're in agreement :-) Either that, or set it to whatever error caused the transaction to be aborted. So the request error would be set to the same as the transaction error. / Jonas We believe that the error granularity you outlined above is more appropriate to be surfaced on the IDBTransaction.onabort or IDBTransaction.onerror handlers. It doesn't seem to be very useful on the IDBOpenRequest associated with the IDBFactory.open method. Also, at the open IDBOpenRequest level, it doesn't seem to matter the reason why the transaction failed, all it matters is that it failed. That is one of the reasons we were suggesting to only surface the AbortError at that level. The other reason is that this will signal the difference in behavior between the IDBOpenRequest and the IDBRequest. Israel
Re: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com wrote: On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com wrote: Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? I realized the other day that the question also applies to what should db.objectStoreNames return? It makes sense that whatever changes we make to .version we'd also make to .objectStoreNames. Do we revert it to the value it had before the transaction was started? Do we throw? Do we return null/0? Ultimately I feel like there really is very little reason for someone to use these properties if the VERSION_CHANGE transaction fails, and so I'm leaning more towards that we should do whatever is easy to implement. So what I suggest is that we do the same thing as for .close(). I.e. we leave the values untouched. This seems not only easy to implement but also is consistent with .close(). / Jonas What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name=assigned db name, version = 0, and objectStoresNames = null. That's fine with me yeah. And what about when .close() is called during the VERSION_CHANGE transaction? / Jonas
RE: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote: On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com wrote: On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com wrote: Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? I realized the other day that the question also applies to what should db.objectStoreNames return? It makes sense that whatever changes we make to .version we'd also make to .objectStoreNames. Do we revert it to the value it had before the transaction was started? Do we throw? Do we return null/0? Ultimately I feel like there really is very little reason for someone to use these properties if the VERSION_CHANGE transaction fails, and so I'm leaning more towards that we should do whatever is easy to implement. So what I suggest is that we do the same thing as for .close(). I.e. we leave the values untouched. This seems not only easy to implement but also is consistent with .close(). / Jonas What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name=assigned db name, version = 0, and objectStoresNames = null. That's fine with me yeah. Cool! And what about when .close() is called during the VERSION_CHANGE transaction? / Jonas For us, when the close method is invoked inside the onupgradeneeded handler, the db is immediately marked to be closed but it is not immediately closed. The db is closed at a later time when no one else is interacting with it. Therefore, closing the db inside the onupgradeneeded handler doesn't do anything to the current transaction. Israel
Re: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
On Wed, Dec 7, 2011 at 3:15 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote: On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com wrote: On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com wrote: Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? I realized the other day that the question also applies to what should db.objectStoreNames return? It makes sense that whatever changes we make to .version we'd also make to .objectStoreNames. Do we revert it to the value it had before the transaction was started? Do we throw? Do we return null/0? Ultimately I feel like there really is very little reason for someone to use these properties if the VERSION_CHANGE transaction fails, and so I'm leaning more towards that we should do whatever is easy to implement. So what I suggest is that we do the same thing as for .close(). I.e. we leave the values untouched. This seems not only easy to implement but also is consistent with .close(). / Jonas What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name=assigned db name, version = 0, and objectStoresNames = null. That's fine with me yeah. Cool! And what about when .close() is called during the VERSION_CHANGE transaction? / Jonas For us, when the close method is invoked inside the onupgradeneeded handler, the db is immediately marked to be closed but it is not immediately closed. The db is closed at a later time when no one else is interacting with it. Therefore, closing the db inside the onupgradeneeded handler doesn't do anything to the current transaction. Yes, that's required by spec. The question is, what does the database-object's .name, .version and .objectStoreNames properties return after the transaction is comitted if the database was closed? / Jonas
RE: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
On Wednesday, December 07, 2011 3:45 PM, Jonas Sicking wrote: On Wed, Dec 7, 2011 at 3:15 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote: On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com wrote: On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com wrote: Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? I realized the other day that the question also applies to what should db.objectStoreNames return? It makes sense that whatever changes we make to .version we'd also make to .objectStoreNames. Do we revert it to the value it had before the transaction was started? Do we throw? Do we return null/0? Ultimately I feel like there really is very little reason for someone to use these properties if the VERSION_CHANGE transaction fails, and so I'm leaning more towards that we should do whatever is easy to implement. So what I suggest is that we do the same thing as for .close(). I.e. we leave the values untouched. This seems not only easy to implement but also is consistent with .close(). / Jonas What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name=assigned db name, version = 0, and objectStoresNames = null. That's fine with me yeah. Cool! And what about when .close() is called during the VERSION_CHANGE transaction? / Jonas For us, when the close method is invoked inside the onupgradeneeded handler, the db is immediately marked to be closed but it is not immediately closed. The db is closed at a later time when no one else is interacting with it. Therefore, closing the db inside the onupgradeneeded handler doesn't do anything to the current transaction. Yes, that's required by spec. The question is, what does the database-object's .name, .version and .objectStoreNames properties return after the transaction is comitted if the database was closed? / Jonas Since the close method is not executed immeditely, my assumption was that it wouldn't have an impact on the VERSION_CHANGE transaction. Therefore, whatever values where committed as part of the VERSION_CHANGE will remain there after the db was closed. Israel
Re: [XHR] chunked
On Wed, Nov 30, 2011 at 7:28 AM, Anne van Kesteren ann...@opera.com wrote: A while ago sicking proposed adding chunked support to XMLHttpRequest: http://lists.w3.org/Archives/**Public/public-webapps/** 2011JulSep/0741.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html https://bugzilla.mozilla.org/**show_bug.cgi?id=687087https://bugzilla.mozilla.org/show_bug.cgi?id=687087 A use case I remember was downloading a large file of some kind that presumably can be incrementally rendered as otherwise responseType blob should be sufficient. More use cases appreciated. Would help with the design. E.g. voice/image search, translation ... IMHO any single resource that involves non-trivial processing to produce would fit the use case. As for the feature, basically have responseType chunked-text and chunked-arraybuffer values and reset rather than update the response entity body with each progress event. And make sure that a progress event is dispatched when the last fetch event is queued. And make sure that this is only available for asynchronous usage. Charles asked whether chunked-text was really needed (and whether we should have chunked which implies ArrayBuffer instead). Nobody got back to him on that. If it is needed, how does it work when you just have some of the bytes of a multi-byte character in a single chunk? Fails to decode as per the normal algorithm? When text is consumed as chunked streams, my take is that the application code has to deal with partial frames, and partial chars are just one sub-problem. So, I wouldn't consider multi-byte characters a particular limitation. Also, this basically makes it possible to write EventSource on top of XMLHttpRequest. Is that acceptable? If it encourages more people to use a lower-level API, higher-level optimizations for mobile phones might become harder down the road. At the same time, lower-level APIs that match the underlying wire-protocol (i.e. HTTP) would be equally important for optimization purposes. Thanks, Wenbo -- Anne van Kesteren http://annevankesteren.nl/
[XHR] chunked requests
One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
