Re: [whatwg] Why is @scoped required for
On Fri, Mar 25, 2011 at 3:37 AM, Boris Zbarsky wrote: > Are there any other reasons to allow
[whatwg] Application Cache (Corrections)
Dear Working Group and Subscribers, i would like to correct myself a little, because i´d been a bit more OT than i wanted to. First of all, you could get me wrong, understanding the cache. I could even cache more pages of my Joomla! with the current. The problem is: Cached once, the files are NEVER being updated again, except the manifest changes a byte. For that, the "modify" function is doing the job. I should better call it "update" function, to point onto the current terms used. You couldn´t read that in my last mail anyways, so you could assume a misunderstanding of the cache on my side. Second thing, the rename of the URLs, or better a local and a network identifier is neccessary. It would be good, if the user agent could care for local identifiers, too. The programmer would sometimes have to give the page a new name to prevent overwriting another file (with access to the cache, maybe even dupe names but other array positions work?). Last - The fourth point should be removed from my suggestion. The caching of the whole request, answer, the two HTTP headers + data sent and received, came when writing the mail. With that i messed the whole content of my suggestion up. I think the request data, the http headers are not so important, because the MIME type IS already cached and there are no more very important informations. I bet you laughed. Otherwise, the whole request is cool, but that messed the mail up. I´ll try to write the "update files in the cache" problem, "how to cache a content manager" and the interfaces (but in webidl) down next. I´ve got the IDL printed for a while and took it with me in the subways some time ago, i should get that working. Hope you can make the cache a bigger -BETTER- component in H5. With friendly regards Edward Gerhold
Re: [whatwg] Canvas.getContext error handling
Based on some discussion[1], it looks like a clean way to handle the "permanent failure" case is: If the GPU is blacklisted, or any other permanent error occurs, treat "webgl" as an unsupported context. This means instead of WebGL's context creation algorithm executing and returning null, it would never be run at all; instead, step 2 of getContext[2] would return null. For transient errors, eg. too many open contexts, return a WebGL context in the "lost" state as Kenneth described. It was mentioned that the GPU blacklist can change as the browser runs. That's supported with this method, since whether a context type is "supported" or not can change over time. Are there any cases where this wouldn't work? (I'm not sure if or how webglcontextcreationerror fits in this. It would either go away entirely, or be wedged between steps 1 and 2 of getContext; I don't know how WebGL would specify that.) [1] http://krijnhoetmer.nl/irc-logs/whatwg/20110413#l-77 [2] http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext -- Glenn Maynard
Re: [whatwg] Canvas.getContext error handling
On Tue, Apr 12, 2011 at 2:21 AM, Boris Zbarsky wrote:
> On 4/12/11 12:06 AM, Ian Hickson wrote:
>>>
>>> Now, that's a problem for WebGL, because it's not possible to tell in
>>> advance whether the underlying rendering context can be created.
>>
>> It would be helpful if someone could explain what conditions could lead to
>> a situation where getContext() could fail to return a WebGL context.
>
> In at least Gecko's implementation, creating of an actual GLContext to back
> the WebGL context could fail. Unfortunately, this can happen any time too
> many WebGL contexts are live; what "too many" means depends on the exact GPU
> resources available.
>
> I think we consider the fact that part a quality of implementation issue,
> though we haven't figured out how to do the "high quality" think here yet.
> ;)
>
>> Is it something the author can do anything about
>
> Still in Gecko's case, drop references to some GL contexts and canvases, and
> hope for GC to happen.
In Chromium the same basic issue is present. We are close to being
able to forcibly evict "old" OpenGL contexts in response, so that
creation of the current one could proceed. In this case the author
wouldn't need to do anything.
There are two more cases I can think of. The first is when the
graphics card or driver version is blacklisted. In this case
getContext() will always return null, and there's nothing the
developer can do. Currently this would be reported via
webglcontextcreationerror. We could consider throwing an exception
containing the detail message.
The second is if the graphics card is in a powered-off state when the
app calls Canvas.getContext("webgl") -- for example, if a notebook is
awakening from sleep. In this case a good quality WebGL implementation
would like to notify the app when the graphics card is available. In
order for this to work, WebGL would actually need to return a non-null
WebGLRenderingContext, but immediately dispatch a webglcontextlost
event to the canvas.
To sum up, in general I think that whenever getContext("webgl")
returns null, it's unrecoverable in a high quality WebGL
implementation.
-Ken
[whatwg] Application Cache Improvement
Dear Subscribers, from the beginning on, i provided almost all functions you would need for a good appcache which is able to cache dynamic websites, e.g. the joomla content manager and the articles behind. The function complex i personally forgot is the "rename urls" complex. Sometimes we would have to rename the url for the use of the page in the cache. Randy´s reply enlightened me, he told me, that sometimes cms systems use a index.php for the whole pages they put out. I remember viewtopic.php from the forums, which always appeared in my old browser, if i tried to save pages, they hadn´t been saved with the name of the head title. I answered something, that i wouldn´t see the values if they are posted, said that a get request with index? postid=1024&catid=512 should always lead to the same place. I could be wrong, i don´t test that, i don´t need for, but i remember no urls in the cache with any paremeters saved, i added none to the manifest. Maybe the string is threatened complete and parameters could also be used, maybe it´s not. Anyways, ... For the extension of the Application Cache. Not caching the Master File is sometimes neccessary, too. For quick changes to the Cache before HTML5 it would be an improvement to let me enter the manifest in Joomla!´s index.php, to blacklist the index.php, but to cache the scripts and styles, and to add pages, i can access from the frontpage on, or try out some fallbacks. CACHE MANIFEST NOMASTER, where NOMASTER is my new token for you. Now a little control is needed for all of the files. I still can´t cache the rest of the pages. How can i cache the files behind the frontpage? The cache with add, del, mod, get for the pages. And begin,seek,pos,next,prev,end for the Cache List. And an event fired after each (including the iterator) of the operations.The event is allowing the programmer to make final changes to the cache. For the iterator a writeback is useful and saves time. If you don´t want to make changes to the cache, just copy the event data over and use the other variable, or just make no changes. If you want to, the writeback of the event data on changes of the data is very useful. Now the new. What is the point, Randy brought you on? The URLs have sometimes to be changed. The cache should have additionally own internal identifiers. There have changes to be made to the URLs for caching the files. Old Url and new Url have to be kept. Both. User Agents SHOULD be able to change and use the old and new urls. User Agents MUST be capable of to manipulate the links the the cached file and the files pointing to. For the extension of the appcache, the has to be 1. The NOMASTER token 2. Additional Functions and an enumerator. And: 3. Rename the Url for Local Use and have Local and Network Url stored. The user agents have to be capable to store cached objects with a new name automatically. The programmer MUST be allowed to manipulate URLs for caching files. He HAS TO be allowed to replace the links pointing to the correct cached file by his Web Application. 3. Let the cache objects have a local name. The GET parameters have to be saved with, the POST data fields could be saved with, (for the List of all urls saved). Leads me to another idea. 4. The Cache Object SHOULD save the whole HTTP Request made to! Exception? On secure pages. You should turn that off on the bank, or? But you won´t cache your bank pages, or? I hope 4. is not making your to do list to long now. But saving all behind index.php (?&=#) and POST is to be considered for comparation of urls in the cache or needed by a good offline reader. Simply writing down the whole request and splitting it up into fields is easier. 4. Write down the request and split it into fields for each cache object. "I have to rewrite all this again." I think i have stated the three (four!) things clear. Enjoy the new issue of the application cache improvement. I´ll keep you up to date with a better formulation, if i can. If you would like to talk about. My channel is open, this channel is, too. With the above i could extend my Joomla! so far, that i could cache the whole CMS. With the actual application cache i can save a boring page, or a good offline application basing on a boring page and much much design, grafix and fancy scripts. But i couldn´t cache a cms and that is shit for the Offline Cache, coz i can´t take my favourite site how far i want to the cache. That´s better than bookmarking, or saving html pages with no connection. The Offline Cache with my saved pages are linked with each other, i can browse it normally, how far i´ve saved it. That´s the aim of my application cache improvement again. 3. Renameability of Urls for the Cache is a MUST. Local and Network Name have to be kept both. 4.Another thing. Write down the whole HTTP Request and split it into fields. Extend the Cache Item with the HTTP fields. Ok and now. Don´t forget the add and enumerate functions for me and my Joomla!, Wordpress, phpBB, Wiki.
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 4/12/11, Lachlan Hunt wrote: > On 2011-04-12 16:18, Lachlan Hunt wrote: >> Ancient Netscape scripting schemes. some were apparently aliases for >> javascript: >> * mocha: >> * livescript: >> * livewire: >> * tcl: > > Correction: tcl wasn't Netscape, it was some other minor browser. Not > sure which one. > Smells like a Netscape plugin to me. [http://www.tcl.tk/software/plugin/] Unless it's simply a name clash.
Re: [whatwg] Blacklist for regsiterProtocolHandler()
* Lachlan Hunt wrote: Also, implementers need to be take care with vendor specific schemes: * chrome: (Mozilla, Chrome) We should probably block these too, for consistency. * view-source: (Mozilla, Chrome) This might have a valid use case in web-based editors like ACE: http://ajaxorg.github.com/ace/build/editor.html (At the cost of not being able to edit and reload the cached version of the page.) -- Wilhelm Joys Andersen Core, Opera Software
Re: [whatwg] How to handle multitrack media resources in HTML
On Apr 11, 2011, at 5:26 PM, Ian Hickson wrote: > On Mon, 11 Apr 2011, Jeroen Wijering wrote: >> On Apr 8, 2011, at 8:54 AM, Ian Hickson wrote: >>> >>> There's a big difference between text tracks, audio tracks, and video >>> tracks. While it makes sense, for instance, to have text tracks >>> enabled but not showing, it makes no sense to do that with audio >>> tracks. >> >> Audio and video tracks require more data, hence it's less preferred to >> allow them being enabled but not showing. If data wasn't an issue, it >> would be great if this were possible; it'd allow instant switching >> between multiple audio dubs, or camera angles. > > I think we mean different things by "active" here. > > The "hidden" state for a text track is one where the UA isn't rendering > the track but the UA is still firing all the events and so forth. I don't > understand what the parallel would be for a video or audio track. > > Text tracks are discontinuous units of potentially overlapping textual > data with position information and other metadata that can be styled with > CSS and can be mutated from script. > > Audio and video tracks are continuous streams of immutable media data. > Video and audio tracks do not necessarily produce continuous output - it is perfectly legal to have "gaps" in either, eg. segments that do not render. Both audio and video tracks can have metadata that affect their rendering: an audio track has a volume metadata that attenuates its contribution to the overall mix-down, and a video track has matrix that controls its rendering. The only thing preventing us from styling a video track with CSS is the lack of definition. > I don't really see what they have in common other than us using the word > "track" to refer to both of them, and that's mostly just an artefact of > the language. > "Track" is more than an artifact of the language, it is the commonly used term in the digital media industry for an independent stream of media samples in a container file. eric
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-12 16:18, Lachlan Hunt wrote: Hi, We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. Our list currently includes: * http: * https: * ftp: * file: Also, blob: Ancient Netscape scripting schemes. some were apparently aliases for javascript: * mocha: * livescript: * livewire: * tcl: Correction: tcl wasn't Netscape, it was some other minor browser. Not sure which one. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Blacklist for regsiterProtocolHandler()
Hi, We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. Our list currently includes: * http: * https: * ftp: * file: * about: * data: Email specific schemes: * cid: * mid: Scripting schemes: * javascript: * vbscript: Ancient Netscape scripting schemes. some were apparently aliases for javascript: * mocha: * livescript: * livewire: * tcl: Also, implementers need to be take care with vendor specific schemes: * chrome: (Mozilla, Chrome) * view-source: (Mozilla, Chrome) * res: (IE) * resource: (Mozilla) * opera: (Opera) * attachment: (Opera) (This list is probably incomplete) We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Canvas.getContext error handling
On 4/12/11 12:06 AM, Ian Hickson wrote: Now, that's a problem for WebGL, because it's not possible to tell in advance whether the underlying rendering context can be created. It would be helpful if someone could explain what conditions could lead to a situation where getContext() could fail to return a WebGL context. In at least Gecko's implementation, creating of an actual GLContext to back the WebGL context could fail. Unfortunately, this can happen any time too many WebGL contexts are live; what "too many" means depends on the exact GPU resources available. I think we consider the fact that part a quality of implementation issue, though we haven't figured out how to do the "high quality" think here yet. ;) Is it something the author can do anything about Still in Gecko's case, drop references to some GL contexts and canvases, and hope for GC to happen. -Boris
Re: [whatwg] Canvas.getContext error handling
On Mon, 11 Apr 2011, Glenn Maynard wrote: > > Now, that's a problem for WebGL, because it's not possible to tell in > advance whether the underlying rendering context can be created. It would be helpful if someone could explain what conditions could lead to a situation where getContext() could fail to return a WebGL context. Is it something the author can do anything about, or is it only likely to happen in situations where the right response from the author is "try reloading the page until it works"? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
