Re: [whatwg] Fetch: please review!
Hi Anne, Your specification contains the following [1]: A response is either CORS-same-origin or CORS-cross-origin. Unless otherwise indicated a response is CORS-same-origin. but it doesn't say what the difference is between the two. The 'CO' in CORS stands for 'cross origin' so 'CORS-same-origin' would mean 'cross origin sharing for the same origin' which sounds a bit strange. 1: http://fetch.spec.whatwg.org/#cors-same-origin On Wed, May 22, 2013 at 2:50 AM, Anne van Kesteren ann...@annevk.nl wrote: I'm reaching the point where I want to start integrating http://fetch.spec.whatwg.org/ into http://xhr.spec.whatwg.org/ so I can remove a lot of the duplicate requirements with respect to networking and at the same time clarify a lot of the networking behavior. And although http://fetch.spec.whatwg.org/ is pretty dry reading it would be good if people could take a look at it as the idea is for it to define the fetching behavior across the platform. This task is currently divided between HTML, CORS, Web Origin Concept, and CSP (integration hooks not yet in Fetch) and creates a real messy situation for specifications building on top of them. The idea is to remove that complexity and have a simple hook for fetching a request and get a response in return. -- http://annevankesteren.nl/
Re: [whatwg] Request: Implementing a Geo Location URI Scheme
On Tue, 4 Jun 2013, Rodrigo Polo wrote: Many apps and web browsers make very difficult to work around geo location data, making a URI scheme available in all web browsers could be great, just like mailto:; opens an email client geo: could open your default maps app on desktop or mobile devices, here I give you a more detailed review, an open letter to all web browser devs: http://rod.gs/fixgeo It's not exactly clear what you want changed to the browsers or the spec. As far as I can tell, geo: is already supported the same way mailto: is. On Tue, 4 Jun 2013, Rodrigo Polo wrote: I know the registerProtocolHandler but it doesn't work exactly as proposed, geo protocol isn't accepted on Chrome only protocols with the web- prefix It should work; it's already listed in the spec. I recommend contacting Chrome developers or filing a bug (http://crbug.com/, click New Issue). and the URL parameter have to match the webpage that make the request, it is designed for websites, not for local apps Yes, registerProtocolHandler() is for Web apps. For native apps, the apps need but use the platform-provided way of registering a URL handler or URL intent, for the scheme geo:, the same way they do for mailto:. On Wed, 5 Jun 2013, Julian Reschke wrote: If you want to geo URIs to invoke a local mapping application, all you need is to install an URI handler fort that scheme and that application in the *operating system*. This is how things like mailto: have been working for two decades now. Indeed. On Wed, 5 Jun 2013, Rodrigo Polo wrote: Hi, well, the kind of support I think should be implemented is actually something that should be a standard, any anchor that have a mailto:; inside is supported out of the box in any web browser and the first time it is clicked the web browser asks for the default app to open that link. As far as I can tell, clicking geo: links does exactly the same as clicking mailto: links, at least in Firefox and Chrome. So, the main idea is to establish a standard way to handle geo location, first by making the URI scheme available on all web browsers and letting the user decide whether he wants to use a local app or a web page to access the links with the URI scheme just as it is done with the mailto:; URI scheme, second step has to be done by the maps developers, they have to give a way to receive this geo location information from the browser and show the user the location, it could be by a URL or a parameter sent to the local binary/executable. As far as I can tell, this is done. If it is poorly implemented, then please file bugs with the implementors. I know this is something that can be achieved very easily by the web browser developer and the maps app developer, the main thing is to make it an standard that everyone uses and that everybody know that it will work just as it works the mailto URI scheme today, I'm very confident that most of the users will appreciate it. I think such standards already exist, both in the form of a geo: URL scheme and in terms of registerProtocolHandler() allowing 'geo:'. The common day to day applications are infinite, useful and enjoyable for anyone, here some examples: Twitter able to detect a geolocation on a tweet and make it a geo link (anchor) so it can be clicked and it will open your map app. Twitter could implement this today; I recommend approaching them to do it. Receiving an emails with geo location coordinates on a link instead of an address and when you click it it opens your preferred maps app or webpage and not the one the user force you to see. E-mail writers can do this today. Common websites have a contact page that can omit showing a map or an address and instead show a link with the geo location. Web sites could do this today. Chat apps like WhatsApp can share geo locations that open on your default app and not into a frame inside that app giving you de possibility to just press the directions to that location to find your way to that point. This is already possible. Indeed on Android (not sure about iOS) it's pretty standard for apps to give geographic/navigation intents. Faceboook fan pages or business pages can have a geo location link and with just a click I can see the location and get directions to that place. This is possible today. Facebook (or facebook users) just have to provide the geo: link, and geography software or Web sites just have to register to handle the URL. The possibilities are limitless but for that to happen it is required that everyone agrees on enabling this URI scheme on all web browsers. As far as I can tell, it is already enabled, modulo some bugs. BTW I know that app makers can add their own URI handler just as the magnet handler works on bittorrent clients, but again isn't available in the markup out of the box. I don't understand what you want out of the box. On Wed, 5 Jun 2013,
Re: [whatwg] Request: Implementing a Geo Location URI Scheme
Just to clarify: Are you requesting to have the geo protocol be handled by the browser itself, without requiring users to install additional software, and without requiring websites to register the protocol in advance? I assume by out of the box you mean that as soon as you install the browser and type a geo URL the browser will handle the geo protocol itself, perhaps by displaying a browser-specific Web page for that geo URL. Am I right? I have no opinion on whether your proposal is good or not. --Peter -Original Message- From: Rodrigo Polo Sent: Wednesday, June 05, 2013 8:00 AM To: Julian Reschke Cc: whatwg@lists.whatwg.org ; Glenn Maynard ; Nils Dagsson Moskopp Subject: Re: [whatwg] Request: Implementing a Geo Location URI Scheme You are completely right, but in the tests I made on Chrome the geo URI handler can't be used with the registerProtocolHandler call, it throws a security error and the use of geo location URI it is not included as a recommendation or good practice when we talk about the markup, so it is not a technical thing, it is more an idea that could be included in further discussions between web browsers developers, map app developers and the users so everyone adopt the idea of having the geo URI scheme adopted as an standard, I'm quite sure this idea can help a lot of users and web developers to give a better user experience and it is more important that many other things, it will make the life of users a lot easier.
[whatwg] Add EXIF metadata support in Canvas.toBlob?
If the second argument to Canvas.toBlob() and Canvas.toBlobHD() is image/jpeg, then these methods support a third argument to specify JPEG compression level. The spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#a-serialization-of-the-bitmap-as-a-file) says: A future version of this specification will probably define other parameters to be passed to these methods to allow authors to more carefully control compression settings, image metadata, etc. I would like to propose the addition of a fourth argument (for the JPEG case only) that would specify EXIF metadata to be included in the JPEG blob. (I have not tried yet, but I'm assuming that we could define some suitable JSON serialization format for EXIF data. If not, then even allowing a binary blob of EXIF data as the fourth argument would be helpful.) The use case for this feature is image editing applications, like the Gallery app on FirefoxOS devices. Whenever that app crops or edits a photo it encodes the edited photo with Canvas.toBlob(), and the process strips all metadata from the photo. Reading EXIF data from a JPEG blob is relatively straightforward can can be done with JavaScript, but inserting EXIF data into an existing blob is much harder: this is a task that is best done when the JPEG blob is being created, which means that it is a feature that belongs in toBlob and can not be done efficiently with an external library. [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.] David Flanagan
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
On Sun, 2 Jun 2013, Martin Janecke wrote: I'm in charge of a code generator and while it is not widespread at all, my opinion might be shared by others who make code generators: This new option is too verbose � especially for something that has no meaning for the document it is contained in. And it kind of sounds as if the particular generator using this attribute is more inapt than other generators who output img src=� alt=image As developer of a code generator I don't feel inclined to use this new non-conforming attribute instead of an inappropriate img src=� alt=image or It would definitely be unfortunate if you wanted to use that instead of img src=... generator-unable-to-provide-required-alt. img src=� alt= or This is, per the spec, a valid last-resort option for you to use (and if you have any reason to believe the image is decorative, it's the best option as well). img src=� title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. While I can imagine why an accessibility evangelist would want a conformance-checker-silencer to be as unattractive to use as possible, that really defeats its purpose, if it also deters code generator programmers. The goal isn't to make it unattractive per se, it's to make it obvious that it means that it was a markup generator that was forced into the bad position of having to output invalid code against its will, in such a way that an author wouldn't conclude that it makes sense to mark up the page this way in order to get around validators. Previously, conformance checkers had been silenced by a single meta name=generator content=� in cases of missing alt-attributes. This solution effectively removed any urge to use an inappropriate alt-text for me as a code generator developer. Yeah. As I recall, this approach wasn't popular with validators, amongst others. :-( I don't know whether someones writes something like �� which the following figure illustrates� instead of �� which is illustrated by fig. 3� somewhere in the text above a figure. But this difference decides whether using the figure element conforms with the spec. So a code generator can only use something which is structurally and optically identical to the figure element but does not have the theoretical requirement to be movable to a different place in the document, e.g.: div class=figure img src=� div class=caption�/div /div And here conformance checkers will complain about the missing alt-attribute again � If you use img src=... title=... it'll work (and be correct, insofar as anything missing alt text can be correct). On Sun, 2 Jun 2013, Jukka K. Korpela wrote: The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. It's not that speculative, your e-mail is a response to a markup generator implementor who feels pressured in exactly this way! Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. It's worse because it prevents authors from being able to find images that are lacking good alternative text, and because it makes it less likely that future user agents will try to automatically figure out what the alternative text should be (since one is already provided). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Add EXIF metadata support in Canvas.toBlob?
On Fri, Jun 7, 2013 at 1:42 PM, David Flanagan dflana...@mozilla.com wrote: If the second argument to Canvas.toBlob() and Canvas.toBlobHD() is image/jpeg, then these methods support a third argument to specify JPEG compression level. The spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#a-serialization-of-the-bitmap-as-a-file) says: A future version of this specification will probably define other parameters to be passed to these methods to allow authors to more carefully control compression settings, image metadata, etc. I would like to propose the addition of a fourth argument (for the JPEG case only) that would specify EXIF metadata to be included in the JPEG blob. (I have not tried yet, but I'm assuming that we could define some suitable JSON serialization format for EXIF data. If not, then even allowing a binary blob of EXIF data as the fourth argument would be helpful.) The use case for this feature is image editing applications, like the Gallery app on FirefoxOS devices. Whenever that app crops or edits a photo it encodes the edited photo with Canvas.toBlob(), and the process strips all metadata from the photo. Reading EXIF data from a JPEG blob is relatively straightforward can can be done with JavaScript, but inserting EXIF data into an existing blob is much harder: this is a task that is best done when the JPEG blob is being created, which means that it is a feature that belongs in toBlob and can not be done efficiently with an external library. [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.] If someone goes through the work of defining an EXIF - JSON mapping then this is something I'd be interested to see added to the spec. It definitely would be nice to enable modifying EXIF metadata without having to re-encode the pixel data since that leads to loss of quality. / Jonas
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
2013-06-08 0:13, Ian Hickson wrote: On Sun, 2 Jun 2013, Jukka K. Korpela wrote: The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. It's not that speculative, your e-mail is a response to a markup generator implementor who feels pressured in exactly this way! And who wrote that generator-unable-to-provide-required-alt is... inadequate. Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. It's worse because it prevents authors from being able to find images that are lacking good alternative text, and because it makes it less likely that future user agents will try to automatically figure out what the alternative text should be (since one is already provided). To a user, even “(an image)” is better than lack of alt attribute, which is what generator-unable-to-provide-required-alt really means. And in the case of user-submitted images, “(a user-submitted image)” might be even better. Lack of alt can mean just about anything; there are millions if not billions of images without alt attribute just because an author did not think of the issue. A generic text “(an image)” at least suggests that it’s a content image with no obvious alternate text. To analyze which images lack good alternative texts, you need to look at the images in their context. It’s just wrong to assume that they can be identified using some simple automated analysis. And future user agents won’t try to figure out what the alternative text should be, any more than current browsers do such things. It is just wishful thinking to expect such processing, and if browsers tried to do such things, they would just mess things up. Yucca
Re: [whatwg] font security on measureText
On Thu, 2 May 2013, Rik Cabanier wrote:
The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]
If doing these measurements requires using a font that has an origin
that is not the same as that of the Document object that owns the canvas
element (even if using a font means just checking if that font has a
particular glyph in it before falling back to another font), then the
method must throw a SecurityError exception.
Does anyone know what this is?
If you import a font from another origin (without CORS), then this
prevents you from reading its metrics.
It seems to us, that if the font is available to CSS (depending on if
the browser supports CORS for fonts), it should be fine to call
measureText.
Only if CSS prevents cross-origin font loads.
On Thu, 2 May 2013, Rik Cabanier wrote:
So, if my css specifies a font:
@font-face {
font-family: Bitstream Vera Serif Bold;
src: url(http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf;);
}
it seems that the origin of the font is not the same as the document so
measureText won't work. (I'm not that familiar with the verbiage so I
might be mistaken)
Right, that's the idea.
On Fri, 3 May 2013, Boris Zbarsky wrote:
The text at
http://dev.w3.org/csswg/css-fonts/#default-same-origin-restriction and
http://dev.w3.org/csswg/css-fonts/#allowing-cross-origin-font-loading
predates your introduction of the mode values, but clearly corresponds
to the CORS mode, no?
And while browsers are not aligned yet, they did plan to align last I
heard, in that their representatives in the WG had agreed to the above
text.
Of course it's possible some of the browsers involved are just planning
to ignore the spec altogether without bothering to argue to get it
changed to what they think is the right thing.
If browsers align on the above text the HTML spec indeed would no longer
need to worry about this, since there'd no longer be any cross-origin
fonts. Has this occurred?
(Personally I don't really see why we'd limit this to same-origin and
CORS-cross-origin only. It makes loading fonts from other origins a pain.)
On Mon, 6 May 2013, Rik Cabanier wrote:
I logged https://www.w3.org/Bugs/Public/show_bug.cgi?id=21943
In the future, please note that there's no need to file a bug for topics
raised on the WHATWG list -- just one or the other is fine.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2D canvas feature proposal: text decoration
On Fri, 19 Apr 2013 00:48:54 +0400, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 18, 2013 at 1:37 PM, David Dailey ddai...@zoominternet.net wrote: You know, I'm not quite sure why we have text in canvas at all. It's not really text you know -- it's just a bunch of pixels. You can't select it, you can't copy it to the clipboard, it's not accessible without a bunch of effort that authors generally don't use. It's generally illegal in most civilized places. Why not use SVG? It's got text decoration. Text is text. It's just that the more conspiratorial and selfish of the browser vendors back when things were being voted on seemed to push canvas since they already owned it and SVG seemed hard and like they might have to learn something by way of graphics in their corporate portfolios. That's how I see it, anyhow. WHATWG doesn't vote, of course. text ... is generally illegal in most civilized places What is this i don't even Using canvas for serious rendering of text is generally... Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] font security on measureText
On Fri, Jun 7, 2013 at 4:08 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 May 2013, Rik Cabanier wrote:
The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]
If doing these measurements requires using a font that has an origin
that is not the same as that of the Document object that owns the canvas
element (even if using a font means just checking if that font has a
particular glyph in it before falling back to another font), then the
method must throw a SecurityError exception.
Does anyone know what this is?
If you import a font from another origin (without CORS), then this
prevents you from reading its metrics.
It seems to us, that if the font is available to CSS (depending on if
the browser supports CORS for fonts), it should be fine to call
measureText.
Only if CSS prevents cross-origin font loads.
Sure.
My point was, why is canvas defining it here?
It seems that it should rely on whatever CSS does. Defining it in Canvas
might make things go out of sync since someone will have to remember to
update both specs.
On Thu, 2 May 2013, Rik Cabanier wrote:
So, if my css specifies a font:
@font-face {
font-family: Bitstream Vera Serif Bold;
src: url(
http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf;);
}
it seems that the origin of the font is not the same as the document so
measureText won't work. (I'm not that familiar with the verbiage so I
might be mistaken)
Right, that's the idea.
On Fri, 3 May 2013, Boris Zbarsky wrote:
The text at
http://dev.w3.org/csswg/css-fonts/#default-same-origin-restriction and
http://dev.w3.org/csswg/css-fonts/#allowing-cross-origin-font-loading
predates your introduction of the mode values, but clearly corresponds
to the CORS mode, no?
And while browsers are not aligned yet, they did plan to align last I
heard, in that their representatives in the WG had agreed to the above
text.
Of course it's possible some of the browsers involved are just planning
to ignore the spec altogether without bothering to argue to get it
changed to what they think is the right thing.
If browsers align on the above text the HTML spec indeed would no longer
need to worry about this, since there'd no longer be any cross-origin
fonts. Has this occurred?
(Personally I don't really see why we'd limit this to same-origin and
CORS-cross-origin only. It makes loading fonts from other origins a pain.)
On Mon, 6 May 2013, Rik Cabanier wrote:
I logged https://www.w3.org/Bugs/Public/show_bug.cgi?id=21943
In the future, please note that there's no need to file a bug for topics
raised on the WHATWG list -- just one or the other is fine.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] font security on measureText
On 6/7/13 7:08 PM, Ian Hickson wrote: If browsers align on the above text the HTML spec indeed would no longer need to worry about this, since there'd no longer be any cross-origin fonts. Has this occurred? No, though they have all in principle agreed that they plan to when they didn't object to the spec... it's not like it's a surprise, and has been the source of a good bit of discussion in the CSSWG. (Personally I don't really see why we'd limit this to same-origin and CORS-cross-origin only. I suggest doing some background reading on that, then? Again, it's been discussed to death. -Boris
