Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 28, 2013 at 8:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/28/13 9:32 AM, Anne van Kesteren wrote: I'm not sure we need to consider sub-scheme if zip-path can work as it's more complex and not very well thought out. E.g. imagine view-source:zip:http://www.example.org/zip!test.html. What's the issue with that? Gecko supports that (with jar:, not zip:), fwiw. I have two concerns with the scheme-based approach. * It dramatically complicates origin handling. This is something we've seen multiple times in gecko and something that I expect authors will struggle with too. * It makes it impossible to have create a relative URL from inside the zip file to refer to something on the same server but outside of the zip file. Since anything outside of the zip file uses a different scheme, it means that you have to use an absolute URL. Not even URLs starting with / nor // can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. 3) We have implementation experience with the sub-scheme approach and we know it can work just fine (existence proof is jar: in Gecko). The main difficulty it introduces is that computing the origin needs to be done via object accessors, not string-parsing... Do we have any implementation experience with zip-path-like approaches? I don't know about can work just fine. Sure, if everyone does the right thing, then it works. But we're having to strictly enforce that no one does string parsing by hand and instead use URL objects and Principal objects. Neither of which really are an option on the web right now as all URL-related APIs use strings. I don't think relative URIs should ever escape a zip archive (though I do appreciate the way that would let someone replace directories with zipped-up versions of those directories). The reason for that is that allowing it sometimes but not others seems really weird to me, and it seems like we don't want to allow it for toplevel zip archives. Why not? / Jonas
Re: [whatwg] Zip archives as first-class citizens
On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell slightly...@google.com wrote: On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking jo...@sicking.cc wrote: I have two concerns with the scheme-based approach. * It dramatically complicates origin handling. This is something we've seen multiple times in gecko and something that I expect authors will struggle with too. * It makes it impossible to have create a relative URL from inside the zip file to refer to something on the same server but outside of the zip file. Since anything outside of the zip file uses a different scheme, it means that you have to use an absolute URL. Not even URLs starting with / nor // can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. I don't see how that relates to the points. The sub-scheme approach still works with HTTP. Origin handling would be more complicated. Anyway, unless someone volunteers I'll write up a comparison of the various approaches in due course. Meanwhile, I'd still be very much interested in hearing implementer interest as without multi-vendor buy-in this whole exercise is futile. Mozillians appears in favor. Googlers appear somewhat reluctant, and everyone else is silent. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 9:19 PM, Zirak A zi...@mail.com wrote: Currently, a DocumentFragment only inherits from Node, and thus loses methods like getElementById. However, the Selector API (http://www.w3.org/TR/selectors-api/) defines querySelector and querySelectorAll on document fragments. My proposal is to add getElementById (which makes sense, as the document fragment is a root node), getElementsByTagName (and its namespace-sensitive version), getElementsByClassName and getElementsByName - in short, all of the general selection methods available on the Document. Per http://dom.spec.whatwg.org/ this is the wrong forum for DOM. Having said that, our current plan is to rely on the Selectors API (2) and slowly move away from getElement* friends over time, as their return values are less than optimal. getElementById is an exception to this, but the hope is that .querySelector(#test) will be fast enough. If it turns out to be a problem, we should re-evaluate at that point. Concrete suggestions for new traversal APIs should be discussed on www-...@w3.org or the DOM bug database until we decide the more appropriate forum is here, it'd be unfair to the existing community otherwise. If you think I should reply to any of the remainder of this thread please let me know, but I hope this general answer is sufficient. -- http://annevankesteren.nl/
Re: [whatwg] Zip archives as first-class citizens
I can't speak for all of Google, but I'm in favour. On 5 Sep 2013 01:26, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Sep 5, 2013 at 7:18 AM, Alex Russell slightly...@google.com wrote: On Wed, Aug 28, 2013 at 9:20 AM, Jonas Sicking jo...@sicking.cc wrote: I have two concerns with the scheme-based approach. * It dramatically complicates origin handling. This is something we've seen multiple times in gecko and something that I expect authors will struggle with too. * It makes it impossible to have create a relative URL from inside the zip file to refer to something on the same server but outside of the zip file. Since anything outside of the zip file uses a different scheme, it means that you have to use an absolute URL. Not even URLs starting with / nor // can be used. Apologies for being late to the thread. Just wanted to agree with both of these points. This only seems valuable to me if we can do it in the context of http(s)://. I don't see how that relates to the points. The sub-scheme approach still works with HTTP. Origin handling would be more complicated. Anyway, unless someone volunteers I'll write up a comparison of the various approaches in due course. Meanwhile, I'd still be very much interested in hearing implementer interest as without multi-vendor buy-in this whole exercise is futile. Mozillians appears in favor. Googlers appear somewhat reluctant, and everyone else is silent. -- http://annevankesteren.nl/
Re: [whatwg] Alignment of empty buttons
On Thu, 5 Sep 2013, Boris Zbarsky wrote: On 9/4/13 8:07 PM, Ian Hickson wrote: As far as I can tell, browsers keep treating it as an inline-block box in those cases. OK, that works, I guess. That does mean that buttons are a replaced element, clearly, though... Something needs to spell that out. In what sense? The definition of replaced element here: http://www.w3.org/TR/CSS2/conform.html#replaced-element ...doesn't seem to apply to button. The rendering of button is very much in CSS' scope, no? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alignment of empty buttons
On Thu, Sep 5, 2013 at 1:47 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 5 Sep 2013, Boris Zbarsky wrote: On 9/4/13 8:07 PM, Ian Hickson wrote: As far as I can tell, browsers keep treating it as an inline-block box in those cases. OK, that works, I guess. That does mean that buttons are a replaced element, clearly, though... Something needs to spell that out. In what sense? The definition of replaced element here: http://www.w3.org/TR/CSS2/conform.html#replaced-element ...doesn't seem to apply to button. The rendering of button is very much in CSS' scope, no? Technically, no, buttons are still replaced elements. In practice, buttons are pretty much stock CSS elements across all user agents, and we should probably standardize that. ~TJ
Re: [whatwg] Adding 2D Canvas features
On Fri, 28 Jun 2013, Tom Wiltzius wrote: The only major Canvas2D features being actively developed in Chromium right now are: - having a canvas context alpha attribute - text decoration - compositing and blending - canvas access in workers (easily referenced from http://www.chromestatus.com/features) It is concerning to me that the list of other unimplemented features that aren't being worked on could block the standardization of the above (all of which have been discussed on this list at one point, but not all of which are in the spec yet). How can we help reconcile this discrepancy? My goal is for the spec to match the browsers as closely as possible while providing direction for the next set of new features. From my point of view, therefore, there's two ways to reconcile this discrepancy: either the browsers implement what's in the spec, or the spec changes to drop the things that aren't getting implemented. On Fri, 28 Jun 2013, Benoit Jacob wrote: Has the Canvas 2D community considered a WebGL-like model to the introduction of additional features? By the WebGL model, I mean: - Define a core feature set that's conservative and limited, but consistently implemented by all browsers. Enforce consistent support for it by an exhaustive conformance test suite. That's the model we're trying to follow. - Let any additional feature be an extension. The goal is for there to be none of these. - Consider, similar to WebGL, further tightening this process by letting any new feature start at draft status and wait a bit before being approved. That doesn't work. Nobody cares if something is approved or not -- they'll use it if it works and it's what they want. Once people use it, it's not going anywhere, and the spec is de-facto frozen. Typically, the difference that this makes is that draft extensions would be exposed by browsers only behind a flag (a browser option that's not enabled by default). Prerequisites for approval would include: having been implemented and stable for some time, and being covered by a conformance test. You can't tell if something is stable until people are using it, so hiding features behind a flag, once their implementation is complete, doesn't help. On Fri, 28 Jun 2013, Rik Cabanier wrote: If you can get them into 2 stable browsers, I'm very sure that Ian will add it to the specification. It seems that Ian is mostly concerned that we're adding more and more features to the document but they are not being worked on. This makes the WHATWG spec less useful since you can't tell what's implemented or not. (It also makes a lot of useless work for Ian if he has to cut it later.) Precisely. I think what's needed is that the person who proposes a feature and gets it accepted on the mailing list, also needs to follow up and coordinate with the browsers so it actually gets implemented. Certainly a one-browser feature is no good, specced or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding 2D Canvas features
Just FYI, Chrome now has a relatively new bug for Canvas v5 API additions that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.com under the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Simon
Re: [whatwg] Blurry lines in 2D Canvas
On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 23 Jul 2013, Rik Cabanier wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ Not always, only if you don't draw the line aligned with the pixel grid (e.g. you draw a diagonal line, or a horizontal or vertical line that isn't centered in the middle of pixels on the pixels grid, or a horizontal or vertical line whose width isn't an integral number of pixels, etc). The options, on a pixel grid display, are: - don't honour the position precisely -- this leads to very ugly artifacts when animating (lines jerk around), and basically means that the graphics aren't accurate. - instead of describing the shapes as vectors, describe them using programs that can adapt to the position and size they're being drawn at, such that they automatically snap to the pixel grid in a pretty fashion -- this is what fonts do. - try to trick the eye by using anti-aliasing when things don't line up exactly on the pixel grid. The first two really aren't plausible options for canvas. On Wed, 24 Jul 2013, Kornel Lesiński wrote: For 1-pixel lines it could be fixed by allowing authors to specify that path should be stroked with lines aligned to inside/outside of the path (which is a useful feature on its own). https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 On Tue, 23 Jul 2013, Rik Cabanier wrote: Sure, but how can we fix this? What is there to fix? The options above are basically the only options. You can't not do one of them -- there's no way to draw a crisp line that isn't pixel aligned. There's no pixels there. Similarly, there's no way to draw a line that's neither horizontal nor vertical yet is crisp and doesn't look jaggy. The pixels are squares, they don't rotate on modern pixel displays. On Wed, 24 Jul 2013, Kornel Lesiński wrote: Should arc() and bezier curves also be snapped? What if you want a line that touches the curve? That's precisely the problem with snapping -- it is far worse than antialiasing. You can't draw precise shapes if you have snapping. On Wed, 24 Jul 2013, Dirk Schulze wrote: Means implementations would need to take viewport, transformations of the document, transformations on elements in the DOM hierarchy, zoom level, aspect ratio of the canvas, position of the canvas in the document, transformations in the canvas and device pixel resolution into account to snap lines to the correct position on the individual device, right?Otherwise it sounds to be hard to guarantee that you don't see antialiased strokes and lines might snap more then just one device pixel. This would also be a problem for aligning shapes to each other in the canvas I guess. What happens on the next transformation after a drawing operation. Say you draw a line that was snapped to the grid and then you do scale(1.1, 1.1). Shall the implementation redraw the canvas? After all it is an pixel image. A vector based drawing format would be better suited for such a task. Indeed. On Sat, 10 Aug 2013, Rik Cabanier wrote: I was wondering if this is something that happens in Flash as well. It turns out that there's an option called hinting: Keep stroke anchors on full pixels to prevent blurry lines. There's a blog post on what this does: http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html I created an example (in flash sorry) that shows the feature: http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html 2 sets of strokes move across the screen and are also scaled. The top strokes behave like canvas does today. They start of blurry and during the animation they slowly get ticker. For some reason it doesn't look very smooth. The bottom strokes have hinting turned on. They are sharp at the beginning and during the animation they stay the same size until the internal stroke width is large enough. At that point you see a 'jump'. I think canvas should have a similar feature... Can you elaborate on how exactly you would want this to work? How would you avoid the alignment and distortion problems when applying this to anything less trivial than a rectangle? Basically, this would *just* move the control points and the width of paths so the strokes are always aligned to the pixel grid (This would take pixel density and transformations into account). After this, you would draw as usual.
[whatwg] [[GetOwnProperty]] for named properties of the Window object
Hi, I was wondering if anyone could help clarify expected behavior of [[GetOwnProperty]] for named properties of the Window object. (It looks like this falls across the HTML5 WebIDL specs, apologies if this is the wrong place to ask). Per WebIDL’s definition of [Global] (http://dev.w3.org/2006/webapi/WebIDL/#Global) the named properties are exposed on a named properties object on the prototype chain. Per section 4.5.5.1 (http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object) the [[GetOwnProperty]] implementation should return a descriptor with writable set to false, enumerable and configurable set to true. Firefox and Chrome both return descriptors from an object on the prototype chain per the spec, attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]], unless there is another mechanism I’m missing here, enumerable is odd since I don’t think the spec says anything about [[GetOwnPropertyNames]]),so I was hoping to better understand why the spec requires the behaviour it does (or whether I’m just following it incorrectly!) Many thanks, Gavin
Re: [whatwg] Path API feedback
On Tue, Aug 20, 2013 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 26 Apr 2013, Rik Cabanier wrote: I think an author would expect that 'addPathByStrokingPath' and other path methods render as if you stroked/outlined directly on the canvas context. Same goes for 'addPath'. I believe very few people actually want the current behavior that's in the spec. I don't know how true that is. It seems logical to me that this: context.beginPath(); context.rect(0,0,100,100); context.rect(50,50,150,150); context.fill(); ...should do the same as this: var p1 = new Path(); p1.rect(0,0,100,100); var p2 = new Path();s p2.rect(50,50,150,150); var p = new Path(); p.addPath(p1); p.addPath(p2); context.fill(p); ...for any combination of path commands where I've put the rect()s. Yes, that would be reasonable behavior since a path is just an aggregation of segments. The problem happens when you call fill or stroke multiple times. For instance: context.beginPath(); context.rect(0,0,100,100); context.fill(); context.beginPath(); context.rect(200,50,-150,150); context.fill(); Now I want to create a region that covers what was drawn. p1.rect(0,0,100,100); var p2 = new Path();s p2.rect(200,50,-150,150); var p = new Path(); p.addPath(p1); p.addPath(p2); 'p' won't describe the same area as what was filled. I think the spec needs to mention that - sections of the path where both edges are filled should be removed - winding needs to be done so eofill and fill give the same result I've filed a bug for adding something like this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835 I'm not sure exactly what the algorithm should be (as we discussed on IRC today), so if anyone has any input here, please don't hesitate to comment. I can help if needed. I know the skia people are working on this as well. The algorithm is fairly straightforward to describe in prose. Implementation is very hard though... Please do add such help as comments on the bug, that would be very helpful. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding 2D Canvas features
On Thu, Sep 5, 2013 at 3:19 PM, Simon Sarris simon.sar...@gmail.com wrote: Just FYI, Chrome now has a relatively new bug for Canvas v5 API additions that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.comunder the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Yes, although that's probably somewhat misleading as the Chromium contributor who volunteered to help implement those is only human and it's a rather long list. I'll be working with him to prioritize, but it's not like suddenly these can all happen. Meanwhile this doesn't change the other Canvas2D-related work ongoing in the Chromium project, so we're still keen to see some new features added to the Canvas spec. Ian if it would help to identify items in the spec that Chromium doesn't intend to implement (at least any time soon), we can attempt to do so. Simon
Re: [whatwg] Challenging canvas.supportsContext
(I want to be clear that the long delay hinders my ability to continue this
conversation. I'm just one regular Mozilla developer --- I'm not supposed
to be spending a lot of time discussing the canvas standard, and right now,
I can't really afford to. Back when I started this thread in june, I did
have some time to invest in a long conversation on this. Right now I don't.)
Some partial inline responses below.
2013/9/3 Ian Hickson i...@hixie.ch
The long and short of this is that I renamed supportsContext() to
probablySupportsContext(). It's already implemented in WebKit
And that's the real cost of having accepted supportsContext too early in
the HTML spec.
Fundamentally, it addresses a need that none of the other proposals
addressed: how to know whether or not you can expect to be able to do 3D.
It's not 100% reliable, but then neither would actually attempting to
create a context, because creating a context is so expensive on some
platforms that some UAs are going to move to doing it lazily
The only conformant way to do lazy context creation would be to have
getContext return lost contexts, but given that only a tiny minority of
real-world code cares about that concept, that's not going to be feasible
in the foreseeable future. Maybe in a few years, optimistically.
On Wed, 19 Jun 2013, Benoit Jacob wrote:
I'd like to question the usefulness of canvas.supportsContext. I tried to
think of an actual application use case for it, and couldn't find one.
The use case is libraries like Modernizr that want to do feature detection
up-front, but don't want a high performance hit on startup.
However, that only shifts the question to: what is the reason for them
to expose such APIs? In the end, I claim that the only thing that we
should recognize as a reason to add a feature to the HTML spec, is
*application* use cases.
Oh well the use case for knowing whether or not 3D is supported on a
particular device is straight-forward: you want to know which set of
assets and logic to download and run.
Application developer wants things. But these are not necessarily good
ideas, because they may not reflect how things really work. More below.
So let's look at the naive application usage pattern for supportsContext:
if (canvas.supportsContext(webgl)) {
context = canvas.getContext(webgl);
}
The problem is that the same can be achieved with just the getContext
call, and checking whether it succeeded.
Suppose you have an app that has a 3D feature, but it's not immediately
used upon startup. For example, a preview window that is displayed on
request. You want to preload all the code to run the preview window, but
you need to load different code based on whether the device can do 3D or
not. So the use case is more:
if (canvas.supportsContext(webgl))
load3DCode();
else
load2DCode();
// 3D code:
function run() {
context = canvas.getContext(webgl);
// ...
}
If now application developers call probablySupportsContext, it returns
true, they start downloading the WebGL assets, but getContext(webgl)
fails, their application startup experience will be wose, which will
pressure browser developers to optimize the accuracy of
probablySupportsContext, but that's going to be hard and unrewarding.
So my best hope is that application developers don't use
probablySupportsContext.
Instead, they should do their actual getContext call --- the one creating
the context that they will actually want to use --- right at the beginning
of their application startup, and download the right assets based on the
outcome of that getContext.
The downside of course is that assets download becomes gated on getContext
returning. But in practice that's not too bad:
- Only the first getContext in a browser sessing can be really slow (say
100 ms), subsequent ones tend to take less than 5 ms --- not that much
compared to the time to download big assets.
- If any assets are shared between the two code paths, they can be
downloaded first while getContext is running.
You don't want to pay the cost of creating a throw-away 3D context on
startup just to know which scripts to load. It defeats the whole point of
not loading all the code up-front.
I'm not talking about having any throw-away 3d contexts just for testing. I
understand that modernizr has an API that would force it to be implemented
in that way. In my view, that makes it a bad API. There should be only one
context, the one that we actually want to use.
Outside of exceptional cases (out of memory...), the slow path in
getContext is the *success* case, and again, in that case a real
application would want to actually *use* that context.
Not necessarily, as noted above. The canvas you're going to draw to
might not even exist at the point you need to know if it's 3D or not.
Precisely, that's my point: don't cater to the pathological
use-a-separate-throwaway-context use
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 9/5/13 6:02 AM, Anne van Kesteren wrote: Having said that, our current plan is to rely on the Selectors API (2) In that case I think we need to add a function to the platform that CSS-escapes a string. Because right now, writing querySelector(# + id) is a total footgun unless you control the id. In particular, if you're a library you're in trouble... but the hope is that .querySelector(#test) will be fast enough. As I explained in the thread, they have quite different behavior: getElementById takes the ID, but querySelector needs a CSS-escaped form of the ID. I'm happy to raise this point on www-dom if you want. Just let me know. -Boris
Re: [whatwg] Alignment of empty buttons
On 9/5/13 4:47 PM, Ian Hickson wrote: In what sense? In the sense that if its computed display is block but its layout behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and so forth), then it's clearly a replaced element with layout behavior defined by something other than CSS. The definition of replaced element here: http://www.w3.org/TR/CSS2/conform.html#replaced-element ...doesn't seem to apply to button. The rendering of button is very much in CSS' scope, no? Sure doesn't seem to be, since no UA actually renders button style=display: block the way a CSS block renders; they do something totally different which is presumably covered by some other spec (e.g. HTML). -Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
Ccing public-script-coord, since that's the right place for this
discussion (because WebIDL is the relevant specification).
On 9/5/13 6:45 PM, Gavin Barraclough wrote:
Firefox and Chrome both return descriptors from an object on the prototype
chain per the spec
Chrome doesn't quite follow the spec here, for what it's worth: it
returns them from Window.prototype as far as I can tell, not from an
actual named properties object.
attributes of the value are configured differently, with enumerable set to
false, writable and configurable set to true.
Current tip Firefox returns
{configurable:true,enumerable:true,writable:true} and enumerates
the properties. Probably a change from
https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with
the spec in terms of the enumeration behavior.
There seem to be some compelling reasons to follow Firefox / Chrome (writable
true seems more congruent with ECMA262 specified [[Put]]
Indeed. I think the current setup in the spec would make window.foo not
settable if img id=foo exists That seems bad.
unless there is another mechanism I’m missing here, enumerable is odd since I
don’t think the spec says anything about [[GetOwnPropertyNames]])
It doesn't, but it does talk about enumeration; see
http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether
that's applicable to the Named Properties Object is an interesting
question).
Granted, I would rather that were defined in terms of
[[GetOwnPropertyNames]] on the relevant objects instead; that's what
actually needs to happen under the hood anyway.
,so I was hoping to better understand why the spec requires the behaviour it
does (or whether I’m just following it incorrectly!)
I think you're following it correctly; it's just buggy. ;)
-Boris
Re: [whatwg] Parse errors for invalid characters
(2013/09/06 6:08), Geoffrey Sneddon wrote: The phrasing content section states: Text nodes and attribute values must consist of Unicode characters, must not contain U+ characters, must not contain permanently undefined Unicode characters (noncharacters), and must not contain control characters other than space characters. This specification includes extra constraints on the exact value of Text nodes and attribute values depending on their precise context. And the pre-processing the input-stream section states: Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+, U+1FFFE, U+1, U+2FFFE, U+2, U+3FFFE, U+3, U+4FFFE, U+4, U+5FFFE, U+5, U+6FFFE, U+6, U+7FFFE, U+7, U+8FFFE, U+8, U+9FFFE, U+9, U+AFFFE, U+A, U+BFFFE, U+B, U+CFFFE, U+C, U+DFFFE, U+D, U+EFFFE, U+E, U+E, U+F, U+10FFFE, and U+10 are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters). Note the first uses Unicode characters, the second characters — the former excludes surrogates as a conformance requirement. Note that every disallowed non-surrogate character is a parse error. Except U+ or am I missing something? Therefore, it would make sense to make surrogates parse errors. It should be noted that they can only occur in the input stream if they come from script (as they cannot be decoded from the input byte stream as the decoders will never emit a surrogate). which means that this seems ... cubersome ... to implement in a conformance checker. Which reminds me, does # Conformance checkers must report at least one parse error # condition to the user if one or more parse error conditions exist # in the document and must not report parse error conditions if none # exist in the document. Conformance checkers may report more than # one parse error condition if more than one parse error condition # exists in the document. mean validator.nu and Firefox view source are non-conforming because they do nothing about document.write() ? I think we should exempt conformance checkers from scripts instead. Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
[whatwg] Stroking algorithm in Canvas 2d
All, we've looked over the algorithm in the Canvas spec that describes how strokes are computed. [1] We think that this section is making some incorrect assumptions. For instance, the dashes are calculated over the total lenght of all subpaths, but each subpath should be treated separately. It's also a bit strange that the spec is trying to describe how to stroke. For instance, it goes in minute detail on how dashes are applied but the hardest part of stroking (inflating the paths in path perpendicular to the direction) is not described at all. Wouldn't it be better to remove all these steps and simply show the desired effect? If not, what would be the best way to fix the wording? The mailing list or a bug? 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
