Re: [whatwg] Support filters in Canvas
On 30/09/2014 02:20, Markus Stange wrote:
Hi,
I'd like to revive this discussion.
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: “contrast(50%) blur(3px)”
What happened to the effort to create CSS filters programmable in GLSL?
Wasn't that effort addressing canvas filters too? Programmable filters
seem more desirable than a fixed set. Last I heard the CSS filters
effort was exploring ways to limit filter operations to those that would
not allow, for example, the visited state of links to be determined. I
think allowing operations only on same-origin data solves those types of
issues for canvas.
Regards
-Mark
--
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合
が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし
たら削除を行い配信者にご連絡をお願いいたし ます.
NOTE: This electronic mail message may contain confidential and
privileged information from HI Corporation. If you are not the intended
recipient, any disclosure, photocopying, distribution or use of the
contents of the received information is prohibited. If you have received
this e-mail in error, please notify the sender immediately and
permanently delete this message and all related copies.G
Re: [whatwg] Proposal: Wake Lock API
On 2014/07/15 12:21, Marcos Caceres wrote: ## Use cases ... Note that some devices have a stay-awake-while-held feature that solves the problem for many of the suggested use cases such as reading a book. For others, such as maps while driving, the trend towards connecting devices to the in-car infotainment system and using the in-dash display solves the problem. I think the need for this API will disappear in a relatively short time due to better solutions such as these. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] `brand-color` meta extension
On 2014/06/26 12:58, Marcos Caceres wrote: I would be in favor of this. It would be good to support the legacy content as its use on the Web is significant. Search I did back in Oct 2013 found these proprietary tags appeared on something like 1% of pages in Alexa's top 78K pages 1%! Significant? Hardly. Typo? Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] High-density canvases
On 19/06/2014 00:30, Justin Novosad wrote: My main point is, there is potentially significant progress in terms of HD canvas rendering that can be achieved without any changes to the spec (other than perhaps an opt-in flag). If it works out well without an explicit opt-in, legacy websites will benefit. Neat as it sounds, it will do nothing to help WebGL canvases. In WebGL applications have full control of the GL viewport which means they need a way to determine the actual h/w (screen) pixel size of a canvas. Current methods have many issues some of which are documented in the bug I referenced in my previous message. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] High-density canvases
On 13/06/2014 12:42, Robert O'Callahan wrote: Here's an alternative proposal which I think is a bit simpler and more flexible: Expose two new DOM attributes on HTMLCanvasElement: readonly attribute long preferredWidth; readonly attribute long preferredHeight; These attributes are the UA's suggested canvas size for optimizing output quality. It's basically what Ian's proposal would have set as the automatic size. We would also add a preferredsizechange event when those attributes change. I like the functionality but these names really don't convey that functionality. The names you originally proposed over in *Bug 1024493* https://bugzilla.mozilla.org/show_bug.cgi?id=1024493 at mozilla.org, renderedPixelWidth/Height, while not perfect, convey it much better. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Proposal: Locale Preferences API
I sent this quite some time ago but have never seen it on the mailing list so I am sending it again. On 2013/10/31 14:41, Mark Callow wrote: On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: This document proposes an extension to HTML's `Navigator` interface to enable dynamic localization of content. The idea is to expose to script the language tags that represents the user's locale preferences (akin to the language tags that are normally sent with HTTP's `Accept-Languages` header). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. Locale != language so if they are doing the latter it is just wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Proposal: Locale Preferences API
On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: This document proposes an extension to HTML's `Navigator` interface to enable dynamic localization of content. The idea is to expose to script the language tags that represents the user's locale preferences (akin to the language tags that are normally sent with HTTP's `Accept-Languages` header). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. Locale != language so if they are doing the latter it is just wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] [2D Canvas] Proposal: Losing and restoring rendering contexts
On 2013/10/19 3:19, Justin Novosad wrote: Please share your thoughts. I think it these events are needed, unfortunately, as it doesn't look like GPU contexts will be virtualized any time soon. For the open issues, I say yes to the first. Note that this matches what is said about the specification - WebGL will inherit from the parent canvas specification. I say a weak no to the second. Testing can be done with shims and there are probably better ways for apps to do resource management. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Adding features needed for WebGL to ImageBitmap
On 2013/07/18 16:34, K. Gadd wrote: I understand the rationale behind gregg's suggestion for flipY, but ultimately don't know if that one makes any sense in a HTML5 context. It basically only exists because of the annoying disagreement between APIs like OpenGL and other APIs like HTML5 Canvas or Direct3D, specifically about which direction the Y axis goes. It exists because of the annoying disagreement between the orientation of the data in most image file formats and the default orientation for textures images in OpenGL. There are a some image file formats that have a bottom left orientation and there is one, extremely common, format, EXIF, that includes metadata giving the visual orientation of the image. The flipY item in the proposed dictionary could be handily extended to an enum. E.g., * none - leave orientation alone * flipY - ignore the EXIF orientation, just flip in Y * topLeftEXIF - identify visual orientation from EXIF data and re-order data so top-down, left-to-right processing for display results in correct visual orientation * bottomRightEXIF - as above but ordered for bottom-up, left-to-right processing Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Adding features needed for WebGL to ImageBitmap
On 2013/07/15 10:46, Justin Novosad wrote: But to circle back to your point, I agree that an exception is a good idea to avoid having to hold a triplicate copy in RAM, or having to redecode all the time. Better to force the dev to make additional copies explicitly if needed than to make a potentially uselessly costly implementation.mf Maybe I am misunderstanding but the only reason I can see for 3 copies (2 if you ignore the undecoded copy) is if you propose to ignore the specified parameters when drawing the image to a 2D canvas. I would expect to always draw the image decoded as indicated by the proposed parameters so no additional copy would be necessary. Sure the image might not be correct (colors off or image upside down) but that would be a programmer error. I would like to see ImageBitmap fully support WebGL so WebGL apps can use a Browser's built-in image decoders. And, if the rumors are true, come IE11, WebGL will be supported by all major browsers so it should be treated as a first-class citizen. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On 2013/06/29 4:30, Tom Wiltzius wrote: The only major Canvas2D features being actively developed in Chromium right now are: - having a canvas context alpha attribute - text decoration I thought some pretty strong objections were raised to text decoration. Why are you actively developing it? Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Add EXIF metadata support in Canvas.toBlob?
On 2013/06/08 5:42, David Flanagan wrote: [A related, but perhaps too ambitious, proposal is to allow direct read/write access to EXIF metadata via HTMLImageElement. The primary use case for read access is to enable web apps to trivially determine when, where, and how a photo was taken and also to determine authorship and copyright information for an image. The primary use case for write access might be for selectively stripping metadata. It would be nice to be able to protect user privacy with code as simple as |delete image.metadata.geolocation| for example.] I enthusiastically second this. I think the primary use case is to make it trivial for JS to be able to orient an image according to its EXIF orientation when displaying it on the page. And this use case is huge. The vast majority of cameras today tag images with the camera's orientation when a picture is made. Today you have the following choices in order to have the image displayed correctly: 1. create a copy of the image rotated to a top-left orientation 2. manually apply a CSS style that rotates the image according to its specific orientation 3. A hack using BinaryBlobs, extensive knowledge of the EXIF metadata format and I don't know what else. None are appealing. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Add EXIF metadata support in Canvas.toBlob?
On 2013/06/14 12:45, Jonas Sicking wrote: Wouldn't an even better solution be to make browsers support that EXIF metadata and simply render the image correctly without any action from the page? At least assuming that the EXIF metadata for orientation is standardized and implemented consistently between cameras? It would, except that I think it would break a lot of existing web pages whose images have been rotated to a top-left orientation but whose EXIF metadata says something else. There was a period of years after EXIF appeared when many tools did not handle EXIF metadata, but, because it is packaged in a standard APP block of the JPG/JFIF format, may well have copied it unchanged into destination files after processing. Also images on sites using such a feature could appear with incorrect orientation in older browsers. The same could be said of rotating via JS/CSS, that reads EXIF from the HTMLImageElement, but at least the JS could issue a warning and recommend updating to a more recent browser. The EXIF orientation is standardized and handled consistently. However cameras without orientation sensors, i.e., older or cheaper cameras or cell phones, will set it to top left. But users of such cameras will notice the incorrect orientation when viewing on their computers and will rotate the images. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 10:08, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares g...@google.com wrote: O RLY? So you're saying the following 250pt ampersand is stored as a bitmap in the font file? It's not simply stored as a path that you then scale. In some fonts it might be in a completely different format than a path (or it could even be a bitmap) As screen pixel densities soar, it is increasingly the case that fonts are stored simply as paths that are scaled, especially fonts which have thousands of characters. Fonts render different from paths. If your UA doesn't do that, you are doing it wrong. :-) Line art looks different to the human eye than a line of text. Imagina a vertical and a horizontal line rendered with sub-pixel AA; they will look very different. Vertical and horizontal lines won't have any aliasing to begin with so what are you talking about? Text also has the nice property that it's filled with a solid color. I know little about Canvas2D but I do know that PostScript and SVG both support gradients etc. when filling text so your statement is wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 10:08, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares g...@google.com wrote: Fonts render different from paths. If your UA doesn't do that, you are doing it wrong. :-) Line art looks different to the human eye than a line of text. Imagina a vertical and a horizontal line rendered with sub-pixel AA; they will look very different. There are systems that use sub-pixel AA for everything and don't seem to suffer because of it. The Haiku OS https://www.haiku-os.org/blog/andrej_spielmann/2008-07-23/sub_pixel_antialiasing_report_2_gsoc for example. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 13:50, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 9:25 PM, Mark Callow callow.m...@artspark.co.jp mailto:callow.m...@artspark.co.jp wrote: As screen pixel densities soar, it is increasingly the case that fonts are stored simply as paths that are scaled, especially fonts which have thousands of characters. No, that is not true. Talk to font vendors; fonts are not just a collection of path segments. They are also not rendered as paths; instead they should have specific renderers. The people who work on our HiGlyph library tell me it is changing. I have no references I can provide. Vertical and horizontal lines won't have any aliasing to begin with so what are you talking about? Of course they have aliasing. Why wouldn't they? Because they are vertical and horizontal, therefore no jaggies (aliasing). Text also has the nice property that it's filled with a solid color. I know little about Canvas2D but I do know that PostScript and SVG both support gradients etc. when filling text so your statement is wrong. I worked on the rendering engine of Illustrator and Acrobat for 11 years. Subpixel AA is disabled for text that is filled with gradients or images and reverts to normal rendering. AFAIK there is no postscript implementation that supports subpixel positioning. Can you point me to a spec where you can fill text in canvas with a gradient instead of a solid color? As I wrote, I don't know much about Canvas2D. Besides it wasn't clear that your comment referred only to Canvas2D. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/03/13 2:03, Stephen White wrote: Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the opaque attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead.m Could we align this with the existing WebGL canvas attribute instead of having similar but opposite attributes on each. I.e. instead of opaque have alpha. When false the canvas is opaque (and it is not necessary to store alpha values in the backing store). When true, the canvas is potentially translucent. The default for alpha is true so that matches the proposed default for opaque. It will cause much less confusion if the same attribute serves the same purpose on both types of canvas. FYI, the description of the attribute in the WebGL spec is: If the value is true, the drawing buffer has an alpha channel for the purposes of performing OpenGL destination alpha operations and compositing with the page. If the value is false, no alpha buffer is available. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Canvas in Workers
On 2013/01/04 9:46, Gregg Tavares wrote:
On Tue, Dec 11, 2012 at 9:04 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 11 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
In WebGL land we have creation attributes on the drawingbuffer made for a
canvas. Example
gl = canvas.getContext(webgl, { preserveDrawingBuffer: false });
We're working out the details on how to set those options for the case
where we have 1 context and multiple canvases.
The particular option above would apparently be a huge perf win for
canvas 2d for mobile. Which suggests that whatever API is decided on it
would be nice if it worked for both APIs the same.
What does it do?
Effectively it makes the canvas double buffered.
The reason for this attribute and defaulting it to false, is so that
tiled renderers can avoid copying the area of the previously-rendered
drawing buffer corresponding to the current tile, into tile memory prior
to rendering. Avoiding this copy is a big performance and power win for
tiled renderers. As far as I am aware every mobile GPU, with the
exception of NVIDIA's Tegra, is a tiled renderer so supporting them is
very important.
I would expect these wins to be equally important when doing animation
in Canvas2D as I would double buffering to to avoid flicker.
Regards
-Mark
--
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合
が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし
たら削除を行い配信者にご連絡をお願いいたし ます.
NOTE: This electronic mail message may contain confidential and
privileged information from HI Corporation. If you are not the intended
recipient, any disclosure, photocopying, distribution or use of the
contents of the received information is prohibited. If you have received
this e-mail in error, please notify the sender immediately and
permanently delete this message and all related copies.
Re: [whatwg] Canvas in Workers
On 2013/01/09 12:37, Ian Hickson wrote: On Wed, 9 Jan 2013, Mark Callow wrote: I would expect these wins to be equally important when doing animation in Canvas2D as I would double buffering to to avoid flicker. Are implementors interested in a way to make 2D rendering contexts use page flipping instead of double buffering? I don't understand what you mean by page flipping so, even if I were a browser implementer, I couldn't answer. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] video feedback
On 2012/12/18 9:01, Ian Hickson wrote: On Tue, 2 Oct 2012, Jer Noble wrote: The nature of floating point math makes precise frame navigation difficult, if not impossible. Rob's test is especially hairy, given that each frame has a timing bound of [startTime, endTime), and his test attempts to navigate directly to the startTime of a given frame, a value which gives approximately zero room for error. ... That makes sense. Should we add a preciseSeek() method with two arguments that does a seek using the given rational time? I draw your attention to Don't Store that in a float http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and its suggestion to use a double starting at 2^32 to avoid the issue around precision changing with magnitude as the time increases. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] video feedback
On 2012/12/21 2:54, Ian Hickson wrote: On Thu, 20 Dec 2012, Mark Callow wrote: I draw your attention to Don't Store that in a float http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and its suggestion to use a double starting at 2^32 to avoid the issue around precision changing with magnitude as the time increases. Everything in the Web platform already uses doubles. Yes, except as noted by Boris. The important point is the idea of using 2^32 as zero time which means the precision barely changes across the range of time values of interest to games, videos, etc. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] checksum attribute in a href tag
On 2012/10/24 15:11, Mikko Rantalainen wrote: Checksum can help even with encrypted connections. I agree. I have checksum and GPG signature verification failures often enough on files I have downloaded via https that I always check them. Automation would be welcome. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Features for responsive Web design
On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Features for responsive Web design
On 2012/10/10 6:49, Tab Atkins Jr. wrote: On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi One of the devices I saw last week is a 10 display with 299dpi; I strongly suspect it is the one that will be used in this Nexus tablet. The other device is already on sale. A Sharp SH-10D smartphone sold by NTT Docomo. It has a 329 dpi display. http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. I don't know what the browser on the SH-10D is doing, (It's running Android 4.0) but, given the physical size (4.5), if they were making the css pixels smaller, the content would be unreadable. I expect they are actually using 3x. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Hardware accelerated canvas
On 12/09/04 10:02, David Geary wrote: Sure, but those use cases will be in the minority, and we're already talking about a very rare occurrence in the first place, so the odds of a very expensive regeneration on a lost context must be near Lotto levels. It is not a rare occurrence on mobile devices. On my tablet WebGL app's lose their context every time the tablet goes to sleep. Since the timeout is so short, it only take a brief distraction and poof! the tablet is asleep. The loss can happen while the application is in the middle of drawing the canvas. Regards -Mark P.S. Why do so many threads on whatwg get forked? My threaded message viewer is now showing 3 threads with the title Hardware accelerated canvas. -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます。 NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On 12/08/28 14:41, Ian Hickson wrote: On Fri, 8 Jun 2012, Mark Callow wrote: On 08/06/2012 06:09, Ian Hickson wrote: The dire warning doesn't work. I'm just saying that's the direction that operating system vendors have been going in; that disallowing it in the browser case is not a different direction, it's consistent with the industry's direction as a whole. The platform providers want control so they can extract money from application developers; they do it under the guise of safety security so people will go along with it. Governments get control over people in the same way. In both cases it is an existential threat to freedom and civil liberties. If one works from these assumptions, why would we assume that it is nonetheless possible for us to specify something that works against these motivations? We don't. We have to raise awareness of the issues and the level of concern to the point where browser vendors will find acceding to the demands for privacy, and by corollary the ability to fully control one's own devices, the lesser cost option. Putting something in the spec doesn't magically make it appear in browsers. Indeed. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます。 NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Why does CanvasRenderingContext2D.drawImage not draw a video's poster?
On 18/07/2012 13:57, Charles Pritchard wrote: We don't have events based on poster, so we don't know whether or not it's been loaded. On 19/07/2012 09:46, Charles Pritchard wrote: I'm not opposed to the idea, but I'm failing to see the benefit. Still, if there's going to be one, we're going to need an onposterloaded event. I don't understand these concerns. Step 4 of the algorithm to be run when the video element is created or the @poster attribute is set, changed or removed says: Fetch http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch the resulting absolute URL http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#absolute-url, from the element's |Document http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document|'s origin http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin. This must delay the load event http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#delay-the-load-event of the element's document. So once the documented is loaded, the poster, if there is one, will be available. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます。 NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
[whatwg] Why does CanvasRenderingContext2D.drawImage not draw a video's poster?
The spec. for CanvasRenderingContext2D.drawImage says draw nothing when a video element's readyState is HAVE_NOTHING or HAVE_METADATA. I was wondering why this was chosen vs. drawing the poster. A search in the list archive didn't turn up any discussion or explanation. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます。 NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On 19/06/2012 18:56, Chaals McCathieNevile wrote: In both cases it is an existential threat to freedom and civil liberties. I think that is overstating the case. A *lot*. It is not. This is not the venue to discuss this so I will not reply on this list to any further messages but as the simple statement above is unsatisfactory, I will briefly list some supporting points. Re: platform providers Due to Apple's level of control I cannot run the browser of my choice on iOS. The Kindle, Windows 8 Metro, iOS and probably Android and ChromeOS have mechanisms whereby the platform provider can remotely delete applications content and the licenses include language making you give permission for them to do this. One only has to recall how quickly Amazon folded over the Wikileaks matter to see how profoundly dangerous is the mere existence of such capability. Re: government The dangers here are more obvious, such as the systems the US government has put it place by which it can prevent anyone traveling without giving any reason why and those which gather, in massive databases, the photographs and fingerprints of anyone who visits the USA and any legal permanent resident who wishes to travel outside the USA. In these cases, and many others, it is ease of misuse, and government penchant for overreach, which makes these things so dangerous to civil liberties and human rights. Regards -Mark
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On 08/06/2012 06:09, Ian Hickson wrote: The dire warning doesn't work. I'm just saying that's the direction that operating system vendors have been going in; that disallowing it in the browser case is not a different direction, it's consistent with the industry's direction as a whole. The platform providers want control so they can extract money from application developers; they do it under the guise of safety security so people will go along with it. Governments get control over people in the same way. In both cases it is an existential threat to freedom and civil liberties. Regards -Mark
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 06/06/2012 21:36, Henri Sivonen wrote: More to the point, the important characteristic is being able to stop downloading *quarter* way through the file and get results that are as good as if the full-size file had been down sampled with both dimensions halved and that size had been sent as the full file. (I am not aware of a bitmap format suitable for photographs that has this characteristic. I am aware that JPEG 2000 does not have this characteristic. I believe interlaced PNGs have that characteristic, but they aren't suitable for photographs, due to the lossless compression.) IIRC Kodak's PhotoCD image format had this characteristic. The first part is a low res. image, the second is the differences between the low res. image zoomed to the high res. size and the actual high res. image. Regards -Mark
Re: [whatwg] Encoding Standard (mostly complete)
On 19/04/2012 07:34, Glenn Maynard wrote: On Wed, Apr 18, 2012 at 12:12 PM, Anne van Kesteren ann...@opera.comwrote: Then we'd first have to introduce interval syntax to the English language. We could do that I suppose in the Terminology section if you think it would be better. It would also apply to http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#index-gb18030-code-point, and it could apply to select ranges (eg. 7.1 step 5: [0,0x7f]). Maybe it's not enough to be worth figuring out how to define it. All it takes is a couple of short sentences. *Numeric Intervals.* Closed intervals are denoted with square brackets and open intervals with round brackets. For example, [0, 10) denotes the values from zero to ten, including zero but not including ten. I agree with Glenn that using intervals would be clearer as well as being shorter. Regards -Mark
Re: [whatwg] Encoding Standard (mostly complete)
I find having the steps incrementing the byte and code point pointers being before the current byte or code point is processed (except for the EOF check) confusing but a way to make it less confusing is not obvious. Regards -Mark On 17/04/2012 18:30, Anne van Kesteren wrote: Hi, Apart from big5 (which requires some more research) all encoders and decoders are now defined: ...
Re: [whatwg] Client side value for language preference
On 02/04/2012 09:45, Steve Axthelm wrote: On 2012-03-30 Henri Sivonen hsivo...@iki.fi wrote: Is there a reason to believe that this client-side solution would be used significantly considering that the HTTP header has not been used that much? Don't know about significantly, but I recently used the HTTP headers for a group of support pages that had many localizations and would have really liked to have been able to handle the entire logic for that on the front-end. I would love it, if more sites would use these headers. As someone else pointed out, some web servers make it very easy. I would support an equivalent client-side query. The current favourite algorithm among servers seems to be to serve a language based on their perception of your current location. There are so many reasons why this causes them to serve the wrong language, it is beyond my understanding why so many sites do it. As a native English speaker living in Japan, I suffer from it every day. The HTTP headers provide a much better mechanism. Regards -Mark
Re: [whatwg] Endianness of typed arrays
On 28/03/2012 18:13, Boris Zbarsky wrote: What one could do is to store the array buffer bytes always as little endian, and then if sending to the GPU byte-swap as needed based on the API call being used (and hence the exact types the GPU actually expects). So basically, make all JS-visible state always be little-endian, and deal in the one place where you actually need native endianness. Then, if you are on a big-endian system an app will not be able to read write int, float, etc. into the int32Array, float32Array, etc. Typed in TypedArrays will no longer have any meaning. BTW, if the CPU GPU differ in endianness it is the responsibility of the OpenGL driver to handle it. When you tell GL you are passing it, e.g. GL_FLOATs, the values are expected to be in CPU byte-order. Regards -Mark
Re: [whatwg] Endianness of typed arrays
On 28/03/2012 18:33, Boris Zbarsky wrote: On 3/28/12 2:32 AM, Mark Callow wrote: Then, if you are on a big-endian system an app will not be able to read write int, float, etc. into the int32Array, float32Array, etc. Why not? Because you said JS-visible state (will) always be little-endian. Regards -Mark
Re: [whatwg] Endianness of typed arrays
On 28/03/2012 18:45, Boris Zbarsky wrote: On 3/28/12 2:40 AM, Mark Callow wrote: Because you said JS-visible state (will) always be little-endian. So? I don't see the problem, but maybe I'm missing something... The proposal is that if you take an array buffer, treat it as a Uint32Array, and write an integer of the form W | (X 8) | (Y 16) | (Z 24) into it (where W, X, Y, Z are numbers in the range [0,255]), then the byte pattern in the buffer ends up being WXYZ, no matter what native endianness is. Reading the first integer from the Uint32Array view of this data would then return exactly the integer you started with... So now you are saying that only the JS-visible state of ArrayBuffer is little-endian. The JS-visible state of int32Array, etc. is in platform-endiannesss. I took your original statement to mean that all JS-visible state from TypedArrays is little-endian. Regards -Mark
Re: [whatwg] Endianness of typed arrays
vertexAttribPointer lets you specifiy to WebGL the layout and type of
the data in the buffer object. The API follows OpenGL {,ES} for
familiarity and reflects its heritage of a C API avoiding use of
structures. But it works.
OpenGL {,ES} developers typically load data from a serialized form and
perform endianness conversion during deserialization. The serialized
form is what would be loaded into an ArrayBuffer via XHR. It is then
deserialized into 1 or more additional ArrayBuffers.
Regards
-Mark
On 28/03/2012 18:42, Boris Zbarsky wrote:
On 3/28/12 2:22 AM, Jonas Sicking wrote:
Except if the data was written in 32bit units you do a different byte
swapping than if the data was written as 16bit units.
Hmm. I just read the webgl spec more carefully and discovered that
bufferData() actually takes a byte array whose structure is opaque,
which would mean that in that case it does become very difficult to
figure out what the swapping pattern should be. :(
The typed-array spec was specifically designed for use cases like
sending buffers containing data in patterns like 32bit data, 16bit
data, 16bit data, 32bit data, 16bit data, 16bit data
With all due respect, if it were really designed for those use cases
it would allow declaring a type made of 32-bit data, 16-bit data,
16-bit data and then creating an array of such types I
understand we might get such APIs eventually, and then WebGL may end
up usable again on big-endian platforms if developers use those APIs
to fill the array buffer. But as things stand, I think you're right:
creating a browser implementation on big-endian hardware that has
working webgl and works correctly with existing code that gets data
using XHR arraybuffer is impossible as far as I can see.
-Boris
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On 22/03/2012 04:42, Anne van Kesteren wrote: ... As for the API, how about: enc = new Encoder(euc-kr) string1 = enc.encode(bytes1) string2 = enc.encode(bytes2) string3 = enc.eof() // might return empty string if all is fine And similarly you would have dec = new Decoder(shift_jis) bytes = dec.decode(string) Or alternatively you could have a single object that exposes both encode() and decode() and tracks state for both: enc = new Encoding(gb18030) bytes1 = enc.decode(string1) string2 = enc.encode(bytes2) This has encode and decode reversed from my understanding. I regard the string (wide-char) as the canonical form and the bytes as the encoded form. This view is reflected in the widely used terminology charset encodings which refers to the likes of euc-kr and shift_jis. Regards -Mark
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On 17/03/2012 08:19, Boris Zbarsky wrote: I think that trying to get web developers to do this right is a lost cause, esp. because none of them (to a good approximation) have any big-endian systems to test on. On what do you base this oft-repeated assertion? ARM CPUs can work either way. I have no idea how the various licensees are actually setting them up. Regards -Mark
Re: [whatwg] Encodings and the web
On 20/12/2011 20:01, Anne van Kesteren wrote: [3]http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html This is a great start. A few comments It seems weird to use Windows' names rather than the iso names as the official encoding names. E.g., I expected iso-8859-1 to be the encoding and windows-1252 to be one of the labels. Notes still says multi-octet encodings aren't listed at all. Perhaps I am misinterpreting what list of encodings refers to. Including tables for all the multi-octet encodings is going to be a big task and create a very long document. Such tables may be better placed in linked documents rather than the main body. Regards -Mark
Re: [whatwg] Proposal in supporting the writing of Arabizi
Why do you feel it is necessary to sway IME's off OSes? As far as I know the OS ones are all freely downloadable or included in OS distributions. The downloadable ones are not even as hard to find as they used to be. They're needed for all text input fields across the system. They're complicated enough that I wouldn't want to have to learn different ones in different applications. I quite agree about the dictionaries and not just for IMEs. I have a ridiculous number of English dictionaries installed on my system, e.g., one in Thunderbird, one in Firefox, one in MS Office, one in XMLMind, one in Foxit Reader plus a host of others. I also have separate copies of the _same_ Japanese dictionaries in Thunderbird and Firefox for use by the Rikaichan plug-in. However having dictionary look-up only available as a network service is a very dangerous way to go from the perspective of civil rights and liberties. It needs to be a service available locally perhaps with an option to go to the network. Regards -Mark On 05/12/2011 07:42, Sami Eljabali wrote: Thanks Mark for the clarification, and thanks all for the feedback. To the valid point however, regarding the result of bloated web browsers storing each language's dictionary, I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. That said, couldn't we have have 'dictionary look-ups' be served as a service? It could follow the search services model available today, where users choose their provider to be used by the browser itself. This would allow room for providers to even emerge given possible incentives or others including noting trends circulating via users speaking x,y, or z languages. Worst case, one could look into a peer-to-peer solution, where users donate their bandwidth/cpu for others. Your thoughts on this are appreciated.
Re: [whatwg] Proposal in supporting the writing of Arabizi
I think what is being requested by the OP is very very different from the things being requested in the W3C bugs linked from the below referenced wiki page (which seem like good ideas, but please ensure that '+' can be entered in phone numbers). As Sergiusz Wolicki pointed the OP is requesting an IME and IMEs already exist for several languages. The corollary of this is that hooks for IMEs exist in all major operating systems. As Sergiusz also pointed out, users will want this functionality available in any text field. I think it would be better to develop an Arabic IME for the OS rather than embedding it in browsers. Maybe such a thing already exists. Have you any idea of the size of the dictionary and supporting data needed for the Japanese IME? It is quite large. I do not think browser vendors will want to bloat their products with large IME dictionaries for even one language so any browser-based IMEs will inevitably become separate downloads. In which case there is no benefit compared to a separately downloaded OS-based IME and the disadvantage that it can't be used with any text field on the system. Regards -Mark On 02/12/2011 03:36, Tab Atkins Jr. wrote: On Thu, Dec 1, 2011 at 1:07 AM, Sami Eljabali seljab...@gmail.com wrote: [snip] *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread.
Re: [whatwg] Default encoding to UTF-8?
On 01/12/2011 11:29, L. David Baron wrote: The default varies by localization (and within that potentially by platform), and unfortunately that variation does matter. In my experience this is what causes most of the breakage. It leads people to create pages that do not specify the charset encoding. The page works fine in the creator's locale but shows mojibake (garbage characters) for anyone in a different locale. If the default was ASCII everywhere then all authors would see mojibake, unless it really was an ASCII-only page, which would force them to set the charset encoding correctly. Regards -Mark
Re: [whatwg] Suggestion for HTML5 context menus
On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). Is there a way for the user to access the regular context menu? I could imagine it being extremely irritating and even frustrating if one can't access familiar and useful items like Copy link location, Bookmark this page or Select all because the author of some element on the page has decided to redesign the context menu. Regards -Mark
Re: [whatwg] Add naturalOrientation property to img
On 11/08/26 10:03, Tab Atkins Jr. wrote: On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard gl...@zewt.org wrote: Rather than baking magic EXIF constants into the API, would it make more sense to translate to degrees? Possibly. However, 4 of the EXIF orientations (2, 4, 5, and 7) are unnatural orientations that require mirroring the data as well as rotating it. We'd also need to decide whether the reported rotation is how much it differs from upright or the rotation needed to return it to upright (the difference between 90deg and -90deg). The EXIF constants do not represent a degree of rotation. They describe how the rows and columns of the image data map to the top and bottom of the image so more flexible in some ways, as evidenced by the possible unnatural orientations, and less flexible in others. When EXIF orientation is present in the JFIF/EXIF file, I would hope the browser would apply it whenever decoding the file and creating the image object. If it does so , there should remain relatively few cases where the webapp needs to read the image's natural orientation. But I have no objection to such a property being added. Regards -Mark
Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback
There is a lot more that could be done than simply triggering the flash. See /The Frankencamera: An Experimental Platform for Computational Photography/ http://graphics.stanford.edu/papers/fcam/ and The FCAM API http://fcam.garage.maemo.org/. Regards -Mark On 26/07/2011 14:30, Ian Hickson wrote: On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson i...@hixie.ch wrote: Another question is flash. As far as I have seen, there seems to be no option to specify whether the camera needs to use flash or not. Is this decision left up to the device? (If someone is making an app which is just clicking a picture of the person, then it would be nice to have the camera use flash in low light conditions). getUserMedia() returns a video stream, so it wouldn't use a flash. Wouldn't it make sense to have a provision for flash separately then? I think a lot of apps would like just a picture instead of video, and in those cases, flash would be required. Maybe a seperate provision in the spec which defines whether to use flash, and if so, for how many miliseconds. Is that doable?
Re: [whatwg] base in body
On 7/21/11 11:51 PM, Mark Callow wrote: Seems like a bug in the whitelist filter to me. Shouldn't the filter be checking requests using the full URL just before they are dispatched? We're talking a filter on the HTML generation, not in the browser. -Boris Ahh! Got it. Thanks. -Mark
Re: [whatwg] base in body
On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky bzbar...@mit.edu wrote: That said, I'm not sure I understand the security concern. What kind of whitelist-based filter would let through scripts whose URIs it does not control, exactly? Can the security concern be mitigated by only allowing base outside head if the base URI it sets is same-origin with the document? The script is from the page itself and uses a relative URL. The base is inserted by the attacker and causes the script to be requested from a server under the attacker's control. Seems like a bug in the whitelist filter to me. Shouldn't the filter be checking requests using the full URL just before they are dispatched? Regards -Mark
Re: [whatwg] Timing API proposal for measuring intervals
On 08/07/2011 11:54, James Robinson wrote: True. On OS X, however, the CoreVideo and CoreAudio APIs are specified to use a unified time base (see http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html) so if we do end up with APIs saying play this sound at time X, like Chris Roger's proposed Web Audio API provides, it'll be really handy if we have a unified timescale for everyone to refer to. If you are to have any hope of synchronizing a set of media streams you need a common timebase. In TV studios it is called house sync. In the first computers capable of properly synchronizing media streams and in the OpenML specification it was called UST (Unadjusted System Time). This is the monotonic uniformly increasing hardware timestamp referred to in the Web Audio API proposal. Plus ça change. Plus ça même. For synchronization purposes, animation is just another media stream and it must use the same timebase as audio and video. Regards -Mark
