Re: [whatwg] Stroking algorithm in Canvas 2d

[Ian Hickson]

On Wed, 9 Oct 2013, Rik Cabanier wrote:
> > >
> > > Yep, this is where assumptions went wrong. Dashes are calculated per 
> > > subpath, not per 'line'/whole path.
> >
> > On what basis are you asserting this?
> 
> see this fiddle: http://jsfiddle.net/6eGxU/25/

This demonstrates pretty well what is wrong with the algorithm you're 
suggesting (and which is implemented in Chrome). Why shouldn't we take 
this opportunity to fix it?

Here's an even better example of the problem:

   http://goo.gl/hwK7fv

It doesn't make any sense, as far as I can tell, that the lines in the 
discontinuous box would have different gaps than the line in the 
continuous box. They're the same lines. Only the joins should be 
different. Why would we do this?

(Note that in most cases you can simulate the effect of restarting with 
each subpath pretty easily by just painting the subpaths separately, 
instead of as one single path. I don't see any good way to simulate the 
way it's specced with the model you describe.)


> I think most (all?) graphics libraries traces their root back to 
> PostScript. PDF, Core Graphics, Cairo and Direct2D all follow the same 
> algorithm.

If there's a good reason to do this, other than "we've always done it this 
way", then it's certainly a good thing to consider. If none of the 
browsers are willing to implement it the way the spec describes it, that's 
also a reason to change the spec. But just that it's always been done that 
way isn't a reason at all.


> They're not always lines though. What about curves?

Curves are lines too. The spec uses the term "path", though.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

On Wed, Oct 9, 2013 at 9:52 PM, Ian Hickson  wrote:

>
> On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson  wrote:
> > >
> > > The idea here is that this line:
> > >
> > >   --
> > >
> > > ...would result in this dash (assuming equally spaced on-off):
> > >
> > >   ---   ---   ---   ---   ---
> > >
> > > ...while this line, dashed with the same stroke:
> > >
> > >   ---   ---   ---   ---   ---
> > >
> > > ...would result in this different line, rather than result in no
> change:
> > >
> > >   --- --- ---
> > >
> > > ...and this line, dashed with the same stroke:
> > >
> > >   --  --  --  --  --  --  --  --
> > >
> > > ...would result in something more like:
> > >
> > >   --  -   --  -   --  -
> > >
> > > ...rather than, again, resulting in no change.
> >
> > Yep, this is where assumptions went wrong. Dashes are calculated per
> > subpath, not per 'line'/whole path.
>
> On what basis are you asserting this?
>

see this fiddle: http://jsfiddle.net/6eGxU/25/


>
>
> On Thu, 12 Sep 2013, Rik Cabanier wrote:
> >
> > Currently the spec says:
> >
> > 1 Let width be the aggregate length of all the lines of all the subpaths
> in
> > path, in coordinate space units.
> > 2 Let offset be the value of the styles lineDashOffset, in coordinate
> space
> > units.
> > 3 While offset is greater than width, decrement it by width.
> > 4 While offset is less than width, increment it by width.
> >
> > For 1, dashing should be applied to each subpath. As the PDF reference
> > manual says:
>
> What's the relevance of the PDF spec here?
>

I think most (all?) graphics libraries traces their root back to PostScript.
PDF, Core Graphics, Cairo and Direct2D all follow the same algorithm.


>
>
> > 2 - 4 are not correct. From the PDF reference:
>
> Again, I don't see the reference of PDF to this.
>
>
> On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > > > > > It's also a bit strange that the spec is trying to describe how
> > > > > > to stroke.
> > > > >
> > > > > It's trying to describe sufficient detail to get interoperable
> > > > > behaviour.
> > > > >
> > > > > > 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.
> > > > >
> > > > > Is there any ambiguity in the part that's not described?
> > > >
> > > > Yes. What is "inflating"?
> > >
> > > The dictionary definition is what I intended. To grow, increase in
> > > size, get bigger in all directions. Inflate.
> > >
> > > If you have any better suggestion for how to word this, I'm all for
> > > it.
> >
> > I think Stephan could come up with a formula.
>
> I don't really think it needs a formula. The concept is pretty simple. You
> have a line. You just need the path that describes the area that would be
> covered if a line of length equal to the line width was swept along the
> path, while being kept at an angle such that it is orthogonal to the path
> being swept.
>
> I've replaced the text with new text that tries to define this better
> without using "inflate".
>

They're not always lines though. What about curves?


>
>
> > > > A stroked bezier curve is no longer a bezier and has to be
> > > > calculated.
> > >
> > > Yes. The idea of defining it in terms of the earlier path is that
> > > there's no need to be explicit about the maths here.
> >
> > How is a UA going to implement that? I can imagine many ways to
> > "inflate" a path
>
> Is the new text unambiguous enough? If not, what interpretation can you
> come up with which match the new text?


I'm unsure. Stephan, what do you think?

Re: [whatwg] Stroking algorithm in Canvas 2d

[Ian Hickson]

On Fri, 27 Sep 2013, Rik Cabanier wrote:
> On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson  wrote:
> >
> > The idea here is that this line:
> >
> >   --
> >
> > ...would result in this dash (assuming equally spaced on-off):
> >
> >   ---   ---   ---   ---   ---
> >
> > ...while this line, dashed with the same stroke:
> >
> >   ---   ---   ---   ---   ---
> >
> > ...would result in this different line, rather than result in no change:
> >
> >   --- --- ---
> >
> > ...and this line, dashed with the same stroke:
> >
> >   --  --  --  --  --  --  --  --
> >
> > ...would result in something more like:
> >
> >   --  -   --  -   --  -
> >
> > ...rather than, again, resulting in no change.
> 
> Yep, this is where assumptions went wrong. Dashes are calculated per 
> subpath, not per 'line'/whole path.

On what basis are you asserting this?


On Thu, 12 Sep 2013, Rik Cabanier wrote:
>
> Currently the spec says:
> 
> 1 Let width be the aggregate length of all the lines of all the subpaths in
> path, in coordinate space units.
> 2 Let offset be the value of the styles lineDashOffset, in coordinate space
> units.
> 3 While offset is greater than width, decrement it by width.
> 4 While offset is less than width, increment it by width.
> 
> For 1, dashing should be applied to each subpath. As the PDF reference
> manual says:

What's the relevance of the PDF spec here?


> 2 - 4 are not correct. From the PDF reference:

Again, I don't see the reference of PDF to this.


On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > > > > It's also a bit strange that the spec is trying to describe how 
> > > > > to stroke.
> > > >
> > > > It's trying to describe sufficient detail to get interoperable 
> > > > behaviour.
> > > >
> > > > > 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.
> > > >
> > > > Is there any ambiguity in the part that's not described?
> > >
> > > Yes. What is "inflating"?
> >
> > The dictionary definition is what I intended. To grow, increase in 
> > size, get bigger in all directions. Inflate.
> >
> > If you have any better suggestion for how to word this, I'm all for 
> > it.
> 
> I think Stephan could come up with a formula.

I don't really think it needs a formula. The concept is pretty simple. You 
have a line. You just need the path that describes the area that would be 
covered if a line of length equal to the line width was swept along the 
path, while being kept at an angle such that it is orthogonal to the path 
being swept.

I've replaced the text with new text that tries to define this better 
without using "inflate".


> > > A stroked bezier curve is no longer a bezier and has to be 
> > > calculated.
> >
> > Yes. The idea of defining it in terms of the earlier path is that 
> > there's no need to be explicit about the maths here.
> 
> How is a UA going to implement that? I can imagine many ways to 
> "inflate" a path

Is the new text unambiguous enough? If not, what interpretation can you 
come up with which match the new text?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Boris Zbarsky]

On 10/9/13 8:40 PM, Glenn Maynard wrote:

But it's already been suggested--by you--that we need a function to
CSS-escape a string


Sure.  This was just an additional data point as to why: CSS escaping a 
newline is not very obvious.



which seems to solve the that problem trivially (for users).


The ones that know to use it, right.

-Boris

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Domenic Denicola]

Eventually ES6 template strings [1] will make this awesome, as you'll do

querySelector(css`\n`)

or

querySelector(css`[data-some-id=${myId}]`)

or even

qs`[data-some-id=${myId}]`

But someone has to write these functions (css and/or qs) and there's no point 
in creating standard versions until template strings are actually in browsers. 
(Well, modulo transpilers.) In the meantime a CSS escaper function would be 
great and could be used to much more easily prolyfill such template string 
functions, or be useful independently. So, uh, +1 to that idea.

[1]: http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/23

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Glenn Maynard]

On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky  wrote:

> On 6/28/13 10:01 PM, Boris Zbarsky wrote:
>
>> On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
>>
>>> getElementById("foo") is just querySelector("#foo")
>>>
>>
>> This is actually false.  For example, getElementById("foo:bar") is just
>> querySelector("#foo\\:bar"), which is ... nonobvious.
>>
>
> And today someone asked me how to do the equivalent of
> getElementById("\n") with querySelector.  That one is even more non-obvious.


But it's already been suggested--by you--that we need a function to
CSS-escape a string, which seems to solve the that problem trivially (for
users).

I often do things like saving an element's elem.dataset.someId, and then
finding the element again later by saying
container.querySelector('[data-some-id="' + saved_id + '"]'.  (That lets me
find the element later, even if it's been replaced by a new element, which
doesn't work if I just save a reference.)  That would help there, too,
since I wouldn't need to make sure that my IDs don't need to be escaped.

-- 
Glenn Maynard

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Boris Zbarsky]

On 6/28/13 10:01 PM, Boris Zbarsky wrote:

On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:

getElementById("foo") is just querySelector("#foo")


This is actually false.  For example, getElementById("foo:bar") is just
querySelector("#foo\\:bar"), which is ... nonobvious.


And today someone asked me how to do the equivalent of 
getElementById("\n") with querySelector.  That one is even more non-obvious.


-Boris

[whatwg] Possible bug in the way the spec about worker GC behavior

[Ehsan Akhgari]

Right now the spec says[1] "Whenever a Document object is discarded, it
must be removed from the list of the worker's Documents of each worker
whose list contains that Document.".  If I'm reading this correctly, this
implies that the worker object should be alive by the time that the
document gets discarded, which is not what Gecko implements.

Should this be fixed in the spec?

[1] <
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#the-worker%27s-lifetime
>

Cheers,
--
Ehsan

Re: [whatwg] onclose events for MessagePort

[Ehsan Akhgari]

OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose event is impossible since there is no deterministic point in time
before a worker is GCed when we know that it will be GCed soon.

So with that behind us, how about we add an explicit event to be fired when
the other side of a message channel gets destroyed in a catastrophic way
which is not observable from the web content code running on that side,
such as a process crash for example?  The basic idea behind why this more
restricted proposal is useful is that barring the catastrophic failure
case, applications can detect the other cases why further communication may
be impossible (such as navigating away from the page) themselves and notify
the other side of the channel as desired -- it is only the catastrophic
termination case which is not detectable from content script.

How about we add another event named "channeldropped" (pending
bikeshedding) which is fired on a message port if the owner global context
of its entangled port is terminated in a catastrophic way?  Needless to
say, the event will be queued asynchronously with the termination of the
other side, and it will not be affected by garbage collection.

Thoughts?

--
Ehsan



On Tue, Oct 1, 2013 at 6:14 PM, Jonas Sicking  wrote:

> On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky  wrote:
> > On 10/1/13 2:11 PM, Ian Hickson wrote:
> >>
> >> How often do we expect two tabs to be talking to each other though?
> >
> > Or a page to an out-of-process subframe?
>
> Or an out-of-process worker. I would think that in Chrome
> SharedWorkers can come from a separate process, though that might
> change if/when chrome switches to out-of-process iframes.
>
> / Jonas
>

Re: [whatwg] Why are we merging Document and HTMLDocument again?

[Ian Hickson]

On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
> On Sep 13, 2013, at 1:53 AM, Anne van Kesteren  wrote:
> > 
> > It's not entirely clear to me what the suggestion from Ryosuke is. Is 
> > it to keep getters on HTMLDocument only and expose HTMLDocument only 
> > in browsing contexts created from text/html resources? And use 
> > Document everywhere else and have Document contain all the other 
> > members including (former) SVGDocument members? That setup would make 
> > sense to me anyway.
> 
> My proposal something along that line.

Could you be more precise?


On Fri, 13 Sep 2013, Simon Pieters wrote:
>
> Let's list concrete cases and see what we want to do with each one.
> 
> In a browsing context:
> 
> * text/html document (uses interface "Document" and is an "HTML document")
> * XML document (uses interface "Document" and is an "XML document")
> 
> Not in a browsing context:
> 
> * document.implementation.createDocument() (uses interface "XMLDocument" and
>   is an "XML document")
> * document.implementation.createHTMLDocument() (uses interface "Document" and
>   is an "HTML document")
> * new Document() (uses interface "Document" and is an "XML document")
> * XHR response (uses interface "Document" and is an "XML document", even for
>   text/html if I read the spec correctly)
>
> For instance the createHTMLDocument() case currently supports named 
> getter in Gecko but not in Blink. 
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2519

The list above would be a good one to start from. What features would you 
want in which cases?


On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
>
> But HTMLDocument also has a bunch of other junk properties like embeds, 
> plugins, scripts, compatMode, bgColor, fgColor, alinkColor, linkColor, 
> vlinkColor, etc… We even have write() and writeln() there!
> 
> I don’t want to start adding all these legacy methods elsewhere.

These aren't all junk. "scripts" for example is a perfectly valid and 
useful API, which it would definitely make sense to use from within an 
HTML fragment inside an SVG document.

write() and open() are only useful in an HTML context, since it bails if 
the Document is an XML one.

Also, the vast majority of the time, a document is the kind of document 
that needs these APIs. There's not really much of an "elsewhere" for them 
to be found in. It's not like having them in XML documents actually 
affects many people, so not having them doesn't actually help any 
appreciable number of people either.

But, I'm certainly open to having a more elaborate scheme where some APIs 
aren't available everywhere if that's what it takes for us to make SVG-in- 
text/html-HTML and HTML-in-XML-SVG be able to generally use the same APIs.


I think the way to move forward with this would be to describe:

 (a) The different categories that you think should behave differently,
 (b) How each category should behave,
 (c) Within each category, what APIs you think should be available (or,
 possibly better, a general rule to decide what API is available and a 
 brief example of how this is applied to a subset of the total API 
 surface -- we can extrapolate from there)

Currently, the spec has an almost trivial answer to this; there's 
basically just the one category except for XMLDocument which is used in 
some edge cases needed for compat.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?

[Philip Jägenstedt]

On Wed, Oct 9, 2013 at 1:29 PM, Erik Dahlstrom  wrote:
> On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt 
> wrote:
>
> ...
>
>> OK, I hadn't considered that moving this to Element would imply the
>> content attributes being reflected for all namespaces. Even though
>> Blink has the IDL attributes on Element, it looks like the reflection
>> with the content attributes only works for HTMLElement and SVGElement.
>> In other words, "whatever Blink does" doesn't look like something
>> worth standardizing.
>>
>> Erik, does going with "SVGElement implements GlobalEventHandlers"
>> (like Gecko) seems like a way forward for the SVG spec?
>>
>> Philip
>
>
> Given the reasons brought up in this thread I should think that the WG would
> agree that "SVGElement implements GlobalEventHandlers" is an acceptable way
> forward.

OK, that's what I'll try to get implemented in Blink. Thanks all!

Philip

Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?

[Erik Dahlstrom]

On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt   
wrote:


...

OK, I hadn't considered that moving this to Element would imply the
content attributes being reflected for all namespaces. Even though
Blink has the IDL attributes on Element, it looks like the reflection
with the content attributes only works for HTMLElement and SVGElement.
In other words, "whatever Blink does" doesn't look like something
worth standardizing.

Erik, does going with "SVGElement implements GlobalEventHandlers"
(like Gecko) seems like a way forward for the SVG spec?

Philip


Given the reasons brought up in this thread I should think that the WG  
would agree that "SVGElement implements GlobalEventHandlers" is an  
acceptable way forward.



--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?

[Philip Jägenstedt]

On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson  wrote:
> On Tue, 8 Oct 2013, Simon Pieters wrote:
>>
>> I think it would be bad to have an IDL attribute without a working
>> content attribute for a given element. That's just confusing.
>
> Yeah, that's the main reason I wouldn't put this on Element if it was up
> to me. It seems weird to say to everyone around the world that we're
> basically stomping on any content attribute starting with "on". It's one
> thing to take "id", and even maybe ok to take "class" (though that starts
> getting a bit iffy, it's easy to come up with examples where the attribute
> "class" means something different than we do in HTML), but I'm sure
> there's all kinds of vocabularies that have an "onclick" attribute with
> _very_ different semantics than ours. For example, I'm sure there's many
> XML-based UI languages that have onclick="" handlers but I doubt that
> they all use JavaScript and I really doubt that they all have the crazy
> semantics that HTML has:

OK, I hadn't considered that moving this to Element would imply the
content attributes being reflected for all namespaces. Even though
Blink has the IDL attributes on Element, it looks like the reflection
with the content attributes only works for HTMLElement and SVGElement.
In other words, "whatever Blink does" doesn't look like something
worth standardizing.

Erik, does going with "SVGElement implements GlobalEventHandlers"
(like Gecko) seems like a way forward for the SVG spec?

Philip