[Bug 18701] New: FileSystem/FileWriter API needs a method to flush/sync
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18701 Summary: FileSystem/FileWriter API needs a method to flush/sync Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: File API: Writer AssignedTo: er...@google.com ReportedBy: kin...@chromium.org QAContact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Currently webapps cannot control when a flush/sync should be performed after writes, so that it's not really clear what data would be read right after writes. The UA cannot make a good decision about when to flush/sync either. The API should provide a way for webapps to make sure the data they've written are actually written to a persistent storage. -- 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 18289] Support 'column' here for consistency with window.onerror?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18289 Edward O'Connor eocon...@apple.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||eocon...@apple.com, ||public-webapps@w3.org Component|HTML5 spec |Web Workers (editor: Ian ||Hickson) Resolution|INVALID | AssignedTo|dave.n...@w3.org|i...@hixie.ch Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3. ||org --- Comment #2 from Edward O'Connor eocon...@apple.com 2012-08-27 19:33:36 UTC --- Erika, Web Workers exist in a spec published by the Web Applications WG-instead of resolving this as invalid, we should move it to the correct WebApps component for consideration by that WG. -- 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: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Wed, Aug 22, 2012 at 6:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Correct. If we applied CAS on attribute changes, we'd have... problems.
Because you could do something like:
.foo[x=123]{ x: 234; }
.foo[x=234]{ x: 123; }
?
Precisely. Any way around this problem pulls in a lot more complexity
that I don't think is worthwhile.
I suspect it's actually pretty simple to fix. Ban attribute selectors, and
forbid setting the class or id attributes using this language.
It's not that simple. ^_^ You can set the 'checked' attribute, which
activates the :checked pseudo. You can do various things with form
inputs (setting 'required' or 'pattern', setting 'value', setting
'disabled' or 'readonly'), which activate the various input
pseudoclasses. Looking to the future, the reference and column
combinators also respond to attributes in various ways.
I have mixed feelings about this proposal overall, but I think it's a little
weird to use CSS property syntax instead of markup-like attribute syntax to
set attributes. I think this makes the syntax confusingly similar to CSS even
though proposed behavior is quite different. Something like this might make
more sense:
img.placeholder {
src=/images/1x1.gif
alt=
}
In other words, make attribute setting look like attribute syntax.
This is similar to the discussions about monocle-mustache in JS. I
prefer being able to simple re-use the existing CSS parser, but I'm
not completely wedded to it. I'd need some strong opinions from more
relevant parties to switch over, though.
I also think the proposed semi-dynamic behavior of applying only at DOM
insertion time but otherwise being static is super confusing.
Opinions can differ. I think this captures at least 90% of the
use-cases for it, and it's simple to explain, which should help offset
the minor confusion.
And finally, I'm skeptical whether the convenience here is worth adding a
whole new language to the Web Platform technology stack. It is literally just
convenience / syntactic sugar. I'm not sure that rises to the high bar needed
to add an additional language to the Web Platform.
Yeah, this is the major hurdle for this. My hope is that, by reusing
the CSS parser and restricting all the expensive parts of CSS
(dynamicness, remembering where a value came from, etc.), I can pull
the bar down low enough for this to make it.
It is just sugar, but it's *useful* sugar, as evidenced by the fact
that people keep trying to push content attributes into CSS. With
something like this, we can avoid discussions like can we put aria
things into CSS? entirely, because they'll already be handled.
~TJ
Re: Push API draft update
Hi Art, Can you update the Webapps Publication Status page to add Eduardo as co-editor of the Push API draft? We are looking forward to feedback on this update, with the goal of getting to FPWD by TPAC if possible. Thanks, Bryan Sullivan + From: EDUARDO FULLEA CARRERA e...@tid.es Date: Wed, 22 Aug 2012 07:48:49 +0200 To: public-webapps (public-webapps@w3.org) public-webapps@w3.org Cc: bs3...@att.com bs3...@att.com Message-id: 492d97b30609c54fa9ff98b847ea5682b975989...@exclu2k7.hi.inet Hi all, Bryan Sullivan and myself have been working together on updating the Push API draft based upon feedback received and the work being driven by Mozilla and Telefonica to build a Push solution for Firefox OS (B2G). You can find it at: http://dvcs.w3.org/hg/push/raw-file/default/index.html This update does not intend to address yet each and every comment received, as some may deserve further discussions, but we think is a good step forward. We are looking forward to receiving your feedback. Thanks and regards, Eduardo Fullea Telefonica Digital Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
