Re: [whatwg] URL testing
On Fri, Nov 23, 2012 at 8:39 PM, Chris Weber ch...@lookout.net wrote: If this is of use to you I'm happy to hear your suggestions and make adjustments to the test cases, format, or approach. I do have plans to narrate each test case with a descriptive comment, reduce duplication, and add more distinct cases. This is super awesome. Glad you continued with this. I have a few generic points for now: * No special handling for IPv4. IPv4 should work the same as domain names. I.e. the host of http://192/ is 192, not 0.0.0.192. * It's still a bit unclear to me what the best solution is for fragment identifiers. Whether they should be percent escaped or not and whether that should differ between .href and .hash. * IDNA is a rathole. * Ports other than 0-9 will cause a parsing failure (e.g. ퟖ will do that). When are you planning on doing the further cleanup you mention? At some point I can try to go through them in detail and suggest fixes (e.g. via a pull request). -- http://annevankesteren.nl/
Re: [whatwg] URL testing
Michael[tm] Smith m...@w3.org, 2012-11-24 15:11 +0900: Chris Weber ch...@lookout.net, 2012-11-23 11:39 -0800: Hello, I've been trying to follow Anne's work with the URL spec, and working on using the W3C testharness.js for URL testing. I have some URL testing running, with still more work to do: http://www.lookout.net/test/url/ A lot of these tests -- e.g., test 64 and most all of the host tests after that -- seem to be failing not because of the specific cases they're testing but because of a common failure caused by that fact that the URL being tested has no pathname -- and so the expected URL should have no pathname -- but the actual URL has a / appended. Anne just now pointed out to me that per the spec, those are not failures anyway because the expected result is that a / gets appended even if the URL has no path. See step 5 here: http://url.spec.whatwg.org/#concept-url-serializer -- Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] [canvas] inner shadows
On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier caban...@gmail.com wrote: What matters is the shape that is used to calculate the blur (step 1) In your example, that shape is a rectangle so just the rectangle edges will be blurred. That slightly blurred rectangle is then composited with the clipping region in step 4. The end result is a solid rectangle in the shadowcolor that composites on top of the shape. Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html), the output is very close to inner shadow in Photoshop (distance 0, size 22): https://zewt.org/~glenn/canvas-glow.png. (I'm testing against inner shadow instead of inner glow; inner glow seems to do something a little more complex at the blur step than a gaussian blur. Tested in Chrome 21; output in Firefox is different, but I probably need to update.) -- Glenn Maynard
Re: [whatwg] [canvas] inner shadows
On Sat, Nov 24, 2012 at 7:59 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier caban...@gmail.com wrote: What matters is the shape that is used to calculate the blur (step 1) In your example, that shape is a rectangle so just the rectangle edges will be blurred. That slightly blurred rectangle is then composited with the clipping region in step 4. The end result is a solid rectangle in the shadowcolor that composites on top of the shape. Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html), the output is very close to inner shadow in Photoshop (distance 0, size 22): https://zewt.org/~glenn/canvas-glow.png. yes! I forgot that clip doesn't clear the path so his example works. I think it's possible to calculate to calculate the reverse shadow today with temporary backing and compositing. If so, the function to calculate them is not really necessary though it would be still be nice to have a direct way to do an inner shadow. (I'm testing against inner shadow instead of inner glow; inner glow seems to do something a little more complex at the blur step than a gaussian blur. Tested in Chrome 21; output in Firefox is different, but I probably need to update.) True. Glow is a bit more complex than a plain (but not much). Photoshop also does a 'multiply' blend with the shadow by default which improves the look.
Re: [whatwg] [canvas] inner shadows
On Sat, Nov 24, 2012 at 8:36 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 24 Nov 2012, Rik Cabanier wrote: How about the strokes? The example in the OP didn't have them, but you'd have to include them in the fill area. With the new Path objects, you'd just use addPathByStrokingPath(), which would be relatively simple. Unfortunately the winding rules will mess up your shape. (non-zero winding) Take for instance a stroked circle. The stroke which is added with addPathByStrokingPath will always create a hole so you end up with a donut instead of just a slightly larger circle. Right: So long as they don't overlap, that's not generally a problem. But sure, for some complex shapes you'd need some new feature or other, whether it's in shadows or path construction or elsewhere. In the case of a circle, if you wanted to draw the inner shadow over the stroke and the fill, you'd have to create the path as just a fill with the radius increased by half the line width. That seems like a heavy burden to place on the developer. Hopefully there are no round joins, endcaps or dashes. I think addPathByStrokingPath is almost useless. Those methods should all do unions...
Re: [whatwg] [canvas] inner shadows
On Fri, Nov 23, 2012 at 10:30 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Nov 2012, Rik Cabanier wrote: On Fri, Nov 23, 2012 at 8:58 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Nov 2012, Rik Cabanier wrote: Turns out it's relatively easy to do today in canvas; after you've drawn your shape and filled it, just add the following code: c.save(); c.clip(); c.moveTo(0,0); c.lineTo(0,height); c.lineTo(width,height); c.lineTo(width,0); c.closePath(); c.shadowColor = 'black'; c.shadowBlur = 30; c.fill(); c.restore(); I don't think that will work. Shadows are calculated before clipping so they don't follow the clipping path. What matters is how they're painted, and that does follow the clipping path, as far as I can tell (step 4 of the drawing model). What matters is the shape that is used to calculate the blur (step 1) In your example, that shape is a rectangle-- No, no, the rectangle is just added to the existing path. The code snippet above comes _after_ you've drawn the shape. True. I forgot that the clip doesn't do a newpath. Sorry about that! Even if it was right, it would only apply to shapes and only if those shapes didn't have strokes and were completely opaque. That's easy enough, though, you only need to make a shape that is what you want the inner shadow to go over, and then set the fill to black (or anything completely opaque). How about the strokes? The example in the OP didn't have them, but you'd have to include them in the fill area. With the new Path objects, you'd just use addPathByStrokingPath(), which would be relatively simple. Unfortunately the winding rules will mess up your shape. (non-zero winding) Take for instance a stroked circle. The stroke which is added with addPathByStrokingPath will always create a hole so you end up with a donut instead of just a slightly larger circle. It's even easier with the new Path primitives since you can construct a combined path by stroking them all into one. Unfortunately, the current path logic does not support unions. It just does path accumulation which will not give you the desired result. So long as they don't overlap, that's not generally a problem. But sure, for some complex shapes you'd need some new feature or other, whether it's in shadows or path construction or elsewhere. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] inner shadows
On Sat, 24 Nov 2012, Rik Cabanier wrote: How about the strokes? The example in the OP didn't have them, but you'd have to include them in the fill area. With the new Path objects, you'd just use addPathByStrokingPath(), which would be relatively simple. Unfortunately the winding rules will mess up your shape. (non-zero winding) Take for instance a stroked circle. The stroke which is added with addPathByStrokingPath will always create a hole so you end up with a donut instead of just a slightly larger circle. Right: So long as they don't overlap, that's not generally a problem. But sure, for some complex shapes you'd need some new feature or other, whether it's in shadows or path construction or elsewhere. In the case of a circle, if you wanted to draw the inner shadow over the stroke and the fill, you'd have to create the path as just a fill with the radius increased by half the line width. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feature Request: Media Elements as Targets for Links
Excuse me if I am doing something wrong by submitting this by mail. I am doing this for the first time, trying to fill in the template given at http://wiki.whatwg.org/wiki/Problem_Solving as good as I could. Use Case Description: Linking to specific fragments of media is possible via media fragment URIs [1]. However, it is not possible to apply a link to embedded media declaratively, for example to link to a specific point in time for a media element on a page. [1] http://www.w3.org/TR/media-frags/ - Current Limitations: Linking to media using media fragment URIs changes browsing context. - Current Usage and Workarounds: 1. metavid (Videos of United States Congress) uses JavaScript, even though they have CMML transcripts and SRT. 2. I have a podcast ”Warum nicht?“ generated by a software called redokast. Annotations need JavaScript: Click on the timestamps. http://warumnicht.dieweltistgarnichtso.net/wn-15.html https://github.com/erlehmann/redokast - Benefits: Declarative markup would make referring to timed annotations easier. Referring to a specific point in time in a podcast on the same comments, for example, could be possible. Proposed Solutions: - My Solution: Give HTML media elements a name attribut. Make them valid targets for links with a target attribut. - Processing Model: Processing for media elements and the a element needs to change. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target Change “The target attribute, if present, must be a valid browsing context name or keyword. It gives the name of the browsing context that will be used.” to “The target attribute, if present, must be a valid browsing context name or keyword or the name of a media element in the current browsing context. It gives the name of the browsing context or media element that will be used.” http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0 Append after “If the user indicated a specific browsing context when following the hyperlink, or if the user agent is configured to follow hyperlinks by navigating a particular browsing context, then that must be the browsing context that is navigated.” the paragraph “If the user indicated a media element on the current page when following the hyperlink, then change the currentSrc attribute of the media element to the absolute URL given by the href attribute relative to the URL given by the currentSrc of the media element.”. (I am unsure about relative URIs. Would we need to change only the media fragment, and not re-run the initialization steps? What about the media formats given by source elements?) - Limitations (No idea.) - Implementation: (I am not a very clever guy. Someone would need to fill this in.) - Adoption: Users could easily link to parts of media resources on a page. The solution would be backwards compatible for existing UAs that are able to process media fragment URIs as long as absolute URIs are used. A JavaScript polyfill could be used while not all UAs support this feature. Consumers of web pages could easily see what a discussion about a media resource refers to. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] URL testing
On 11/23/2012 10:11 PM, Michael[tm] Smith wrote: I wonder if it might make more sense for the URLs being tested for all those cases to include a / for the pathname. That way they would be further isolated to just testing what they're actually intended to test, rather that what they're instead inadvertently testing currently (the problem of the / being appended). You're right, and it looks like this was a bug during my conversion of the Webkit test cases which did actually concat the trailing / in some tests like host.js. I've sent a pull request with the changes described above. Awesome, thank you! -Chris
Re: [whatwg] URL testing
On 11/24/2012 1:34 AM, Anne van Kesteren wrote: This is super awesome. Glad you continued with this. I have a few generic points for now: * No special handling for IPv4. IPv4 should work the same as domain names. I.e. the host of http://192/ is 192, not 0.0.0.192. * It's still a bit unclear to me what the best solution is for fragment identifiers. Whether they should be percent escaped or not and whether that should differ between .href and .hash. There also appears to be some differences in Unicode normalization (assuming I tested this enough), see: http://web.lookout.net/2012/03/unicode-normalization-in-urls.html In my tests: Safari applied NFC normalization to the path, query, and fragment. Chrome applied NFC normalization to the fragment only. MSIE, Firefox, and Opera did not apply normalization anywhere. * IDNA is a rathole. But it makes for interesting test cases :-) When are you planning on doing the further cleanup you mention? At some point I can try to go through them in detail and suggest fixes (e.g. via a pull request). I plan to do it slowly over the course of the next week or two. - Chris
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? The metrics I've seen show that the magnitude of this problem is approximately 8x (to the extent that it's sensible to represent the magnitude with a number). As far as I can tell, the issue really boils down to the DOM being retained mode and canvas being immediate mode. As the size of the underlying model grows, uploading the entire model into the DOM becomes increasingly uncompetitive with having the application manage the model and drawing using immediate mode because the application can use application-specific knowledge to avoid having to process large portions of the model. I'm unsure what details I'm able to share about these experiments. Justin might know better what we're able to share, but the outcomes are roughly: 1) Uploading the entire document model into DOM (say for a model that requires 1 million elements to represent) causes the application to become completely unusable. Memory consumption goes off the charts, hit testing noticeably lags, etc. We've been working to improve performance here, but there are limits to what we'll be able to achieve. For example, DOM is always going to be a less memory efficient than an application-specific representation. On some rendering benchmarks, a variety of browsers are able to render these models at about 8 fps. 2) Remarkably, the current best candidate is a rendering pipeline that attempts to use the DOM in immediate mode. The application performs some application-specific processing to determine which portions of the model can actually affect what's drawn on screen, and then the application uses innerHTML to create DOM for that portion of the model. (They've experimented with a bunch of choices and innerHTML appears to be the fastest way to use the DOM as an immediate mode API.) Using this pipeline, the application uses reasonable amounts of memory and hit testing, etc, aren't impacted. This pipeline gets about 20 fps. 3) Once they've moved from (1) to (2), you can understand why the next logical step is to use a real immediate mode API, like canvas or WebGL. Approach (2) is totally nutty: there's no way the right design is to build up a giant string of markup and then run it through the parser for every frame. Using canvas, the application has no trouble achieving 60 fps. I think the real question here is how do we want applications with very large models to render? Do we really want them to upload their entire models into DOM? If not, how can we provide them with a high-quality immediate model rendering pipeline. Adam
Re: [whatwg] URL testing
On 11/24/12 5:49 PM, Chris Weber wrote: There also appears to be some differences in Unicode normalization (assuming I tested this enough), see: http://web.lookout.net/2012/03/unicode-normalization-in-urls.html A question. What OS or OSes did you test on? Unicode normalization differs in some browsers depending on the OS (e.g. different behavior on Windows and Mac)... -Boris
Re: [whatwg] [canvas] inner shadows
On Sat, Nov 24, 2012 at 8:21 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Nov 24, 2012 at 7:59 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier caban...@gmail.comwrote: What matters is the shape that is used to calculate the blur (step 1) In your example, that shape is a rectangle so just the rectangle edges will be blurred. That slightly blurred rectangle is then composited with the clipping region in step 4. The end result is a solid rectangle in the shadowcolor that composites on top of the shape. Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html), the output is very close to inner shadow in Photoshop (distance 0, size 22): https://zewt.org/~glenn/canvas-glow.png. yes! I forgot that clip doesn't clear the path so his example works. I think it's possible to calculate to calculate the reverse shadow today with temporary backing and compositing. If so, the function to calculate them is not really necessary though it would be still be nice to have a direct way to do an inner shadow. I put an example of this here: http://jsfiddle.net/cabanier/eav5V/ Unfortunately, Chrome has a bug in its handling of shadows so you have to use a different browser. This case uses a png with an alpha channel, but it can apply to shapes as well. It shows how you can calculate the inner shadow and how you can draw it on top of your content. The fourth canvas contains just the shadow. This is probably what Ian's proposed function would return. (I'm testing against inner shadow instead of inner glow; inner glow seems to do something a little more complex at the blur step than a gaussian blur. Tested in Chrome 21; output in Firefox is different, but I probably need to update.) True. Glow is a bit more complex than a plain (but not much). Photoshop also does a 'multiply' blend with the shadow by default which improves the look.
