Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Elliott Sprehn]

On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky  wrote:

> On 12/1/16 1:41 AM, Chris Holland wrote:
>
>> I think the devil would be in implementation detail. Slapping a
>> "rel/noopener" attribute on a specific link is very deterministic and
>> straightforward from a logic standpoint  Whichever window was created
>> from this link can't control the parent.
>>
>
> It's a much stronger guarantee.  The guarantee is that the parent and the
> created window have no way to see each other at all.  Neither one can read
> any state from the other, or even know the other one exists.
>
> In particular, the idea is that rel="noopener" allows the new window to be
> opened in a separate process, or even a separate browser if desired. The
> only difference between it and the user copying the link and then pasting
> it into some other tab or other program is that a referrer header is sent.
>
> Note that this guarantee makes for fairly simple implementation.
>
> Having a header that opts in all links targeted at anything other than
> _parent, _self, and _top have the noopener behavior would be doable. Having
> a header that opts in some links based on the origin of the link href or
> something would probably be doable.  Having a header that tries to add some
> sort of new mode wherein the two windows _can_ see each other but can't do
> some things that they can normally do would be a snake pit of complexity
> that is best avoided.


I would like us to think about adding a mode where you get a MessageChannel
between the two windows. There's no synchronous access, and no ability to
navigate it, but you can talk back and forth with it.


>
>
> -Boris
>

Re: [whatwg] OffscreenCanvas from a worker and synchronization with DOM/CSS

[Elliott Sprehn]

I presume you're supposed to just postMessage back to the main thread when
you commit(). The spec should probably have a "commit" event though.
On Jan 23, 2016 1:49 PM, "Gregg Tavares"  wrote:

> I just noticed Firefox shipped an OffscreenCanvas implementation. Looking
> at the spec it seems there is no way to synchronize updates from a worker
> with dom/css manipulations.
>
> Was this already discussed? There are web apps that synchronize HTML dom
> elements with canvas updates. I'm sure they'd all love to gain the benefits
> of being able to render to their canvas from a worker. But, if they can't
> synchronize the canvas update with their DOM element position updates there
> will be unacceptable skewing/judder/issues
>
> Maybe it was already decided but I couldn't find the discussion. It seems
> like a pretty bold thing to do for HTML because it basically encourages
> using as little HTML/DOM/CSS as possible rather than encouraging just doing
> some fancy rendering in a worker and the rest in HTML.
>
> A few example of apps that would love to get the benefit of offscreen
> rendering in a worker but could not without some way to synchronize
>
> Apple Maps
> https://youtu.be/bBs3sqH27Kk
>
> Baidu Maps
> https://youtu.be/dT-k-xI5UYw
>
> Yahoo Japan Maps
> https://youtu.be/DYVEILUCRZQ
>
> Worse, those things that could have been HTML but are no longer HTML can't
> be used in standard ways. For example because Yahoo Japan's Maps use HTML a
> translation extension, Rikaikun, is able to provide translations. The
> current OffscreenCanvas spec effectively discourages using HTML elements in
> these cases making features like these impossible.
>
> Rakaikun on Yahoo Japan Maps
> https://youtu.be/sQ68V8ggwB0
>
> Another example which would seem really relevant to WebVR is to allow
> various parts of a scene to be presented as a fully functional web page
> like this example
>
>
>
> http://learningthreejs.com/blog/2013/04/30/closing-the-gap-between-html-and-webgl/
>
> but that won't work if you can't synchronize dom and offscreencanvas.
>

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[Elliott Sprehn]

On Sat, Jul 11, 2015 at 11:40 PM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote:
  What Anne describes is perfect!  I'm not hung up on the value of
 cancelable
  itself - some internal bit on Event that makes preventDefault a no-op (or
  event throw) during listener invocation is fine with me (and I agree -
 less
  weird).  If code really wants to test whether it's call to preventDefault
  took effect, it can check defaultPrevented afterward.

 No, that is not what I said. I said we'd disable preventDefault() for
 the listeners that have this bit set. If all listeners for a given
 event have the bit said, the UA can make the optimization.
 [...]


This is what I had in mind as well. Also it occurs to me there's a missing
primitive here for how the browser knows that all listeners have mayCancel:
false so it can make this optimization. EventTarget needs some kind of
method like:

boolean hasOnlyPassiveEventListeners(DOMString type)

so the scroll system can query if all listeners have mayCancel: false to
make the optimization.

Adding this also has the advantage of making it easy to feature detect if
the browser supports this, just look to see if
the hasOnlyPassiveEventListeners property exists on Node.

- E

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[Elliott Sprehn]

On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers rby...@chromium.org wrote:

 On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote:

 ...

 I agree 100% with this principle.  Changed mayCancel to default to false:

 https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140
 .

 This raises a related question though - is the 'mayCancel' name strong
 enough to indicate performance implications to developers?  I personally
 still kind of like the 'blocksScroll' design instead:
 https://github.com/RByers/EventListenerOptions/issues/14


I don't like making this specific to scrolling, that doesn't explain what
it really means in terms of the capabilities of the event handler. We
probably want to use this for other event types where we want to change the
time the event dispatches based on if you require the ability to cancel or
not as well.

- E

Re: [whatwg] Site-Wide Heading Element

[Elliott Sprehn]

On Wed, Jun 24, 2015 at 3:30 PM, Barry Smith bearzt...@live.com wrote:

 ...


 When I build a website that is to have more than one page, and I want the
 banner to be the same across all pages,  I use the header element with
 a
 javascript file embedded inside, like this:

 header id=banner
script src=scripts/header.js type=text/javascript/script
 /header

 and the javascript file looks like this:

 document.write('\
hgroup class=myHeader\
h1The Site Name/h1\
h2Site Tagline/h2\
/hgroup\
 ');

 This way the h1 element is still free to use as the main body heading in
 the document itself.


Please don't use document.write like this, do a server side include instead.

- E

Re: [whatwg] A mask= advisory flag for link rel=icon

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor eocon...@apple.com wrote:

 Hi Elliott,

 You wrote:

  I'm fine with either interpretation, mask-icon or icon mask like
  alternate stylesheet. I don't think adding a mask attribute to the
  HTMLLinkElement for this makes sense.

 Could you elaborate? It's not clear to me why link rel=icon mask
 wouldn't make sense, but link rel=icon sizes does. They are both
 useful advisory hints that help UAs avoid redundant resource loads.


Do you plan to add the mask attribute to img, picture and CSS?

sizes is a generic feature that's available for all image resources.

- E

Re: [whatwg] A mask= advisory flag for link rel=icon

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:

 On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn espr...@chromium.org
 wrote:
  sizes is a generic feature that's available for all image resources.

 No it's not; img sizes and link sizes are completely unrelated.


:( That's really confusing:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes

In any case, I don't think adding a boolean mask attribute to link
specific to the icon type makes sense.

- E

Re: [whatwg] A mask= advisory flag for link rel=icon

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 12:43 PM, Maciej Stachowiak m...@apple.com wrote:


  On Jun 15, 2015, at 5:40 PM, Justin Dolske dol...@mozilla.com wrote:
 
  Hmm, I suppose Elliott's proposal is a bit ambiguous, but I read it as
  fixing the ordering issue by adding a separate mask rel value. Such
 that
  the following are equivalent and independent of ordering:
 
  A) link rel=icon href=colorful.pnglink rel=mask href=black.svg
  B) link rel=mask href=black.svglink rel=icon href=colorful.png
 
  And if  someone actually did want the same icon for both, they could do:
 
  C) link rel=icon mask href=blackhole.svg

 That isn’t how I interpreted Elliot’s proposal.

 That said, if we do make a new standalone rel value for mask icons, I
 would suggest mask-icon or something like that instead of mask, since
 mask is too generic a term.



I'm fine with either interpretation, mask-icon or icon mask like
alternate stylesheet. I don't think adding a mask attribute to the
HTMLLinkElement for this makes sense.

- E

Re: [whatwg] A mask= advisory flag for link rel=icon

[Elliott Sprehn]

Adding a whole new attribute for this seems like overkill, why not use the
rel.

link rel=icon mask href=... sizes=...

That's what the rel list was designed for.

On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com
wrote:

 When link is used to pull in external resources, authors may use
 several attributes as hints about the linked resource to help UAs decide
 whether or not to load it.
 ...

 This combines well with the other resource hints we already have:

 link rel=icon href=mask.svg type=image/svg+xml sizes=any mask

 There are any number of properties UAs might want to use when deciding
 whether or not to load a resource, so you might think we shouldn't add a
 new, one-off attribute every time we identify one. Instead, we could add
 a generic hints attribute and have it take a space-separated list of
 advisory info about the resource.


That space separated list already exists, it's called rel.

- E

Re: [whatwg] An API for unhandled promise rejections

[Elliott Sprehn]

On Tue, May 19, 2015 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola d...@domenic.me wrote:
  It's hard to say what this you're talking about implementing in
 Chrome in
  terms of the task-queueing behavior.  Is that something you just haven't
  decided on yet?
 
  Yeah, I think this will be something that gets nailed down more during
 implementation and writing of test cases.

 That sounds hard to provide feedback on...


Note that of the options mentioned above, there's no way to have a task
after all tasks or a a microtask after all microtasks because both are
loops so there's no concept of after all.

At best it seems either this posts a task or a microtask.

- E

Re: [whatwg] An API for unhandled promise rejections

[Elliott Sprehn]

What of the many things in that email are you considering?

On Mon, May 18, 2015 at 3:49 PM, Domenic Denicola d...@domenic.me wrote:

 Ping. We're considering implementing this in Chrome and it would be
 helpful to get a sense if other vendors support this.

  -Original Message-
  From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
  Domenic Denicola
  Sent: Monday, February 9, 2015 20:45
  To: WHATWG
  Cc: Petka Antonov
  Subject: Re: [whatwg] An API for unhandled promise rejections
 
  An update on this: although the conversation somewhat fizzled here, in
 io.js
  (Node.js fork) something very similar is landing and I'm trying to guide
 it
  toward being reasonably compatible with browsers [1]. Additionally
 several
  promise libraries have implemented similar hooks (see [2] and links in
 the
  comments; also of interest is the analysis of how promise-using
 libraries use
  these hooks).
 
  The community largely settled on unhandledRejection/rejectionHandled,
  instead of hijacking the error event like the original post below
 proposes.
  Which is not to say that we have to respect that in browsers, but it's a
 data
  point to consider.
 
  One interesting question that came up is the exact timing of the
  unhandledRejection event. In my proto-spec at [3] I proposed queuing a
  separate notify-rejected task for each rejection, largely because it
 seemed
  the easiest thing to spec. We now have some experience from the field.
 The
  implementation at [1] considered a few approaches and cycled through
  implementing some subset of them to make a progressively-larger set of
  tests pass:
 
  - Queue a single task
  - Queue a separate task per rejection (as in proto-spec)
  - Queue a microtask that occurs after all other microtasks
  - Queue a task that occurs after all other tasks
 
  Hopefully Petka, CC'ed, can correct me if I misstated these and fill in
 any
  details I missed.
 
  In general I am in favor of pushing off notification as long as possible
 to give
  more time for the rejection to potentially become handled (and thus
  decrease false positives). From this perspective either separate task per
  rejection or after-all-others task seems good. I was hoping to get a web
  platform perspective on what sounds good and would be implementable?
  For example I think the after-all-others-task can be specced with a new
 task
  source that HTML mandates is drained after all others, right?
 
  Anyway, I mostly just wanted to give people an update and show that we're
  prototyping this in io.js. Hopefully the interchange of ideas here can
 help
  push the progress in browsers too.
 
 
  [1]: https://github.com/iojs/io.js/pull/758
  [2]: https://gist.github.com/benjamingr/0237932cee84712951a2
  [3]: https://gist.github.com/domenic/9b40029f59f29b822f3b#promise-error-
  handling-hooks-rough-spec-algorithm
 
 
  -Original Message-
  From: Domenic Denicola
  Sent: Friday, September 12, 2014 14:34
  To: WHATWG
  Subject: An API for unhandled promise rejections
 
  ## Problem
 
  A common desire in web programming is to log any uncaught exceptions
  back to the server. The typical method for doing this is
 
  window.onerror = (message, url, line, column, error) = {
// log `error` back to the server
  };
 
  When programming asynchronously with promises, asynchronous
  exceptions are encapsulated as _rejected promises_. They can be caught
  and handled with `promise.catch(err = ...)`, and propagate up through an
  asynchronous call stack (i.e. a promise chain) in a similar manner to
  synchronous errors.
 
  However, for promises, there is no notion of the top-level of the
 promise
  chain at which the rejection is known to be unhandled. Promises are
  inherently temporal, and at any time code that has access to a given
 promise
  could handle the rejection it encapsulates. Thus, unlike with synchronous
  code, there is not an ever-growing list of unhandled exceptions: instead,
  there is a growing and shrinking list of currently-unhandled rejections.
 
  For developers to be able to debug promises effectively, this live list
 of
  currently-unhandled rejections certainly needs to be exposed via
 developer
  tools, similar to how devtools exposes the ever-growing list of unhandled
  exceptions (via console output). However, developer tools are not
 sufficient
  to satisfy the telemetry use case, i.e. the use case which is currently
 handled
  via `window.onerror` for synchronous code.
 
  ## Proposed Solution
 
  We propose that
 
  1. `window.onerror` be extended to handle the rejected-promise use case,
  notifying about any promises that, at the end of the task queue,
 contain
  rejections that are not yet handled; and 2. A new hook,
  `window.onrejectionhandled`, be added, to notify when (or if) such
  rejections eventually become handled.
 
  By at the end of the task queue I mean that upon a promise being
 rejected
  with no handlers, we would queue a task to 

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

[Elliott Sprehn]

On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 5/7/15 5:07 PM, Tab Atkins Jr. wrote:

 I believe the SVGWG is fine with a parsing-based approach, exactly
 like what HTML does.  An SVG element created with mixed casing, or
 imported from an XML document, might not match a lowercase tagname
 selector, but SVG written in HTML will.


 Hmm.  The main problem here is for scripts that create SVG elements in an
 HTML document, since those have to use createElementNS and pass the
 mixed-case names (e.g. for foreignObject).


One idea could be to make createElement() return SVG elements for svg tag
names embedded in HTML.

Neither spec is ever going to have a conflicting tag name.

- E

Re: [whatwg] High-density canvases

[Elliott Sprehn]

On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad ju...@google.com wrote:

 In the interest of moving forward with this, I began an experimental
 implementation of the renderedPixelWidth/Height propsal (
 https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink.  I ran
 into
 some issues, which I documented in the issues section of the proposal.  I
 would like to draw your attentions to them at this point:

 1. Hard to determine a rendered size when the canvas is not attached to the
 DOM. Perhaps in that case the current intrinsic size should be returned?
 2. After a layout change that affects rendered pixel size, there is no
 guarantee that the size change event will be handled before the layout
 change is propagated to screen, so the content may be temporarily displayed
 in an inconsistent state. Note: the same issue exists with existing methods
 that may be based on mutation observers or window.onresize, for example.
 Though it is not the stated objective of this proposal to solve this
 synchronization problem, there may be an opportunity to do so.


MutationObservers fire in the micro task, which is always before the next
paint (actually before the next task). window.onresize runs at
requestAnimationFrame time in Chrome which also means it never misses the
next paint.

3. Accessing rendered pixel size is layout-inducing. To avoid layout
 thrashing, we should consider making this an asynchronous getter (e.g.
 asyncGetBoundignClientRect). This would also prevent renderedsizechanged
 events from firing from within the evaluation of the
 renderedPixelWidth/Height
 attributes, which is weird.


renderedsizechanged feels like it's related to the general per element
resize event problem. It'd be unfortunate to add an event to the browser
specifically for canvas instead of solving the general problem. In that
case authors will start resorting to hacks where they insert canvases into
the page to listen for resizes (we've seen this with other events like
overflowchanged).

Perhaps we should add per element resize events and spec that they fire
after the layout, but before the paint, during normal frame creation. That
does mean you can cause an infinite loop if your resize handler keeps
mutating the page, but there's so many other ways to cause that already.

- E

Re: [whatwg] resize events on elements

[Elliott Sprehn]

On Tue, Feb 24, 2015 at 12:34 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:

 On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa rn...@apple.com wrote:
  On Feb 23, 2015, at 5:40 PM, Dean Jackson d...@apple.com wrote:
  At the recent Houdini meeting there was a vague agreement between the
 browser engines on adding a way for elements to be notified when their size
 changes. We've run into a number of scenarios where this is extremely
 useful, and is otherwise difficult or annoying (e.g. checking your size on
 a timer).
 
  The idea was to allow the resize event on elements. I don't really care
 what the solution is, so maybe someone here can come up with a better idea
 (size observers?). And of course there are a lot of details to be worked
 out.
 
  I would like it be an async event on an element although we might want
 it to fire earlier than setTimeout(~, 0) to avoid FOC (maybe the same
 timing as rAF?).  I don't think end-of-microtask makes sense as that may
 force too many layouts.

 Yeah, you almost certainly want to tie it to rAF timing.


To support this without missing a frame we'd have to force an extra layout
before rAF to queue the event. That does mean we'd do one extra layout per
frame if your resize handler changed anything.

- E

Re: [whatwg] Should onblur be triggered for hidden nodes?

[Elliott Sprehn]

On Thu, Jan 8, 2015 at 3:38 AM, Rob Wu r...@robwu.nl wrote:

 The spec of the focusing algorithm [1] is not explicit about removed/hidden
 nodes. It seems to allow the change / blur / focusout events to be
 dispatched when an element becomes hidden or is removed from the document.

 All non-WebKit-based users agents (Trident, Gecko, Presto) do NOT follow
 this behavior. I.e. upon node removal, the change/blur/focusout events are
 not dispatched.
 WebKit and Blink deviate from the other UAs, they do trigger these events (
 crbug.com/439484).

 This discrepancy became even more significant when Blink started to match
 other UA's behaviors and focus anchor elements upon click (
 crbug.com/388666#c10). Now, out of all browsers that focus an a element
 upon click, Blink is the only one that triggers the blur event when a node
 is hidden/removed. This difference has caused some broken websites and bug
 reports.

 There are two options here:
 - Dispatch change / blur / focusout when an element is unfocused,
 regardless of whether the element is still in the document.
 - Ignore hidden / removed elements in the focusing algorithm; i.e. do not
 dispatch these events.

 I'm inclined to vote for the second option, because the majority of the
 distinct user agents already follow this behavior.
 What do you think?


I'd support doing this, having to fire blur events when nodes are removed
has been a frequent source of security bugs and complexity in WebKit/blink.

This does mean you can't do certain fancy focus behaviors, but given that
most browsers don't do it anyway we should get rid of it.



 Kind regards,
  Rob
  https://robwu.nl

 [1]

 https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-one

Re: [whatwg] How to expose caption tracks without TextTrackCues

[Elliott Sprehn]

What does UA rendered mean? How does the UA render it? Can the UA just
convert the format into WebVTT instead?

On Mon, Oct 13, 2014 at 11:15 AM, Bob Lund b.l...@cablelabs.com wrote:



 On 10/12/14, 3:45 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:

 Hi all,
 
 In the Inband Text Tracks Community Group we've recently had a
 discussion about a proposal by HbbTV. I'd like to bring it up here to
 get some opinions on how to resolve the issue.
 
 (The discussion thread is at
 http://lists.w3.org/Archives/Public/public-inbandtracks/2014Sep/0008.html
 , but let me summarize it here, because it's a bit spread out.)
 
 The proposed use case is as follows:
 * there are MPEG-2 files that have an audio, a video and several caption
 tracks
 * the caption tracks are not in WebVTT format but in formats that
 existing Digital TV receivers are already capable of decoding and
 displaying (e.g. CEA708, DVB-T, DVB-S, TTML)
 * there is no intention to standardize a TextTrackCue format for those
 other formats (statements are: there are too many formats to deal
 with, a set-top-box won't need access to cues)
 
 The request was to expose such caption tracks as textTracks:
 interface HTMLMediaElement : HTMLElement {
 ...
   readonly attribute TextTrackList textTracks;
 ...
 }
 
 Then, the TextTrack interface would list them as a kind=captions,
 but without any cues, since they're not exposed. This then allows
 turning the caption tracks on/off via JavaScript. However, for
 JavaScript it is indistinguishable from a text track that has no
 captions. So the suggestion was to introduce a new kind=UARendered.

 A clarification - the suggestion was for a new TextTrack.mode value of
 ³UARendered² and for this type of TextTrack the only valid modes would be
 ³UARendered² and ³disabled². The ³hidden² and ³showing² modes would not be
 allowed since no Cues are generated. @kind would continue to denote the
 type of TextTrack.

 Bob
 
 
 My suggestion was to instead treat such tracks as burnt-in video
 tracks (by combination with the main video track):
 interface HTMLMediaElement : HTMLElement {
 ...
 
 readonly attribute VideoTrackList videoTracks;
 ...
 }
 
 Using the VideoTrack interface it would list them as a kind=captions
 and would thus also be able to be activated by JavaScript. The
 downside would that if you have N video tracks and m caption tracks in
 the media file, you'd have to expose NxM videoTracks in the interface.
 
 
 So, given this, should we introduce a kind=UARendered or expose such
 tracks a videoTracks or is there another solution that we're
 overlooking?
 
 Silvia.

Re: [whatwg] Preventing wake lock leaks with DOM nodes

[Elliott Sprehn]

This is what the attached and detached callbacks are for on custom
elements. Someone can build an app-screenlock element that requests the
lock when it's attached (added to the viewed document) and releases when
it's detached (removed from the viewed document).

There's no reason to complicate this API, developers have the primitives to
do this already.


On Mon, Aug 18, 2014 at 6:20 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres w...@marcosc.com wrote:
  The reason I didn't make it a boolean was because of the IPC involved
 and because I wanted to support multiple types of locks without needing to
 add new attributes in the future (and if we need to add the complex stuff
 later).

 What's the problem with adding more attributes in the future?

 That said, I do think that a timeout for screen locks make sense, so
 a boolean wouldn't work. Though not as a timeout for when to release
 the lock, but rather as a minimum time I'd like to keep the screen
 awake as described at

 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297423.html

 / Jonas

Re: [whatwg] Canvas-Only Document Type

[Elliott Sprehn]

On Tue, Jul 8, 2014 at 7:37 AM, Brian Blakely anewpage.me...@gmail.com
wrote:

 I agree, that would be valuable.  This proposal is coming from the
 direction that sweeping out the main thread, and leaving only what is
 necessary for a full Canvas experience, would benefit such
 experiences.


Blink doesn't actually schedule anything related to CSS or layout on the
main thread if all you're doing is drawing to canvas so you wouldn't be
saving any main thread time. I doubt having those features is causing you
any jank. They do use some memory, but for a document with nothing but a
canvas I suspect it's very little.

- E

Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?

[Elliott Sprehn]

On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote:

 On Tue, 13 May 2014, Dirk Schulze wrote:
 
  contentEditable can be fairly useful in SVG as well. It partly works for
  inline SVG content in web browsers today.
 
  The question is, should SVGElement add support for
  contentEditable/isContentEditable and add it to its interface? Or should
  both attributes move to the Element interface instead?

 I would be very careful about moving global attributes to Element. Doing
 so implies that we are adding them to _all_ XML namespaces. That's a huge
 change to propose. Even with class it's IMHO going a bit far (we're
 saying that the semantics of myvocab:teacher class=.../ are that it's
 a space-separate list of CSS class names, even if the vocab designer
 intended it to be a room name or whatever).


@class is a strange thing to make applicable to all random elements in all
namespaces. Even so, in WebKit and Blink we do actually support it on
Element which means that's already the case.



 I would feel more comfortable putting things on SVG, MathML, and HTML
 explicitly.



I don't think we want contenteditable in SVG or MathML. Almost all of the
operations don't make sense. What does intending in SVG do? What does
making something italic? What happens when you hit enter? We can't just
insert a new line in SVG, does it add some space between all the shapes?
Where does your caret actually appear?

We might want some new kind of Web Editing API, but
contenteditable/execCommand are both pretty specific to HTML.

- E

Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS

[Elliott Sprehn]

On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert dholb...@mozilla.comwrote:

 On 01/23/2014 03:16 AM, Stewart Brodie wrote:
  [2] I only noticed one rendering difference -- IE11 honors border on
  br, unlike the other browsers that I tested. (It still doesn't honor
  e.g. display/width/height, though.)
 
  I get different results on your test case for the bottom two tests.  In
  Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26
  there isn't.

 Yeah -- sorry, I thought up those last two testcases (applying float
 and position:absolute to br) a bit later, after I sent my initial
 email. (which is why I didn't mention them as a rendering difference)

 So, the position  float properties do represent a little bit of
 style that Gecko honors on br (but not Blink/Presto; not sure about IE).


Blink treats br (conceptually) like a subclass of Text, there's nothing
to style because it's just a run of text with a forced break.

- E

Re: [whatwg] Comments on dialog

[Elliott Sprehn]

On Wed, Dec 18, 2013 at 4:58 PM, Brian Blakely anewpage.me...@gmail.comwrote:

 On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson i...@hixie.ch wrote:

  On Wed, 18 Dec 2013, Brian Blakely wrote:
   On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote:
   
I've added a rule to the spec that says that viewports have to be
pannable so you can see all of a dialog, but I don't know how
 feasible
that really is.
  
   I could see implementations using shadow divs to satisfy this It
 might
   be beneficial to even codify kind of element as ::modal, representing a
   modal layer acting as an ancestor for both the ::backdrop and dialog.
 
  Not really sure how this would work. Can you elaborate?
 

 This is what the shadow DOM would look like for modal dialogs:

 ::modal
 -  ::backdrop
 -  dialog

 ::modal is dialog's ancestor, and is available when showModal is called.
  This allows authors to set CSS overflow to whichever value suits their
 use-case, and for user agents to establish overflow: auto as the default,
 making the dialog inherently pannable when it exceeds the viewport.


We can't implement that inside Blink. It requires dialog to have two
parents, the real one in the DOM and ::modal. The only way I can see this
working is if we special case the Shadow DOM projection logic for dialog
so that it is always projected into ::modal, but we don't want any special
cases in projection.

- E

Re: [whatwg] Add input Switch Type

[Elliott Sprehn]

On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote:

 Realistically speaking, I don't think this will help much at all. Few
 websites like using the default styling for form controls anyway and
 so people would be just as unhappy with the default switch rendering
 as they are with the default checkbox rendering.

 The real fix is to allow styling formcontrols. It's one of the most
 requested features from web developers, yet no one has taken the time
 to research what it would take to do it.

 I'm quite sure that if someone comes up with a comprehensive and well
 researched proposal, that browsers would jump on it.

 And the fact that we now have shadow DOM defined should help a whole lot.


+1, a switch is just a styled checkbox. We don't need more input types or
attributes, we just need to standardize how to style type=checkbox.

- E

Re: [whatwg] Questions regarding Path object

[Elliott Sprehn]

On Monday, November 18, 2013, Rik Cabanier wrote:




 On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan 
 rob...@ocallahan.orgjavascript:_e({}, 'cvml', 'rob...@ocallahan.org');
  wrote:

 On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski 
 jussi.kallioko...@gmail.com javascript:_e({}, 'cvml',
 'jussi.kallioko...@gmail.com'); wrote:

 Path is also too generic even in the context of graphics. If we later on
 want to add a path object for 3-dimensional paths, you end up with Path
 and
 Path3D? Yay for consistency. Path2D would immediately inform what
 dimensions we're dealing with and also that this is to do with graphics,
 and thus sounds like a good name to me.


 Sounds good to me.


 Elliot,

 what do you think, is Path2D acceptable?


Sounds great to me, lets do it!

- E

Re: [whatwg] Questions regarding Path object

[Elliott Sprehn]

On Mon, Nov 4, 2013 at 9:14 AM, Rik Cabanier caban...@gmail.com wrote:

 On Mon, Nov 4, 2013 at 2:07 AM, Jürg Lehni li...@scratchdisk.com wrote:

  Thinking more about this discussion, I had an idea for an approach that
  would avoid such future clashes all together:
 
  Instead of exposing constructors, why not simply expose the methods that
  create them?
 
  There already are such functions for gradients:
 
  ctx.createRadialGradient()
  ctx.createLinearGradient()
 
  Wouldn't it have been more aligned with this existing API also to have a
  ctx.createPath() ?


 The SVG WG would like to start using the 'Path' object for its objects as
 well. We'd like this to be a generic object that can be used by other parts
 of the web platform.
 It would be strange to require a canvas context just to create pathh.


I'd like to again say I don't think this thing should be called Path. Lots
of other things have Paths, like maps, file systems, urls, why does the
drawing one get to take the global namespace?

Given that there's a bunch of new objects with Drawing as the prefix, I
think we should name this DrawingPath like DrawingStyle and friends.

- E

Re: [whatwg] Questions regarding Path object

[Elliott Sprehn]

On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze dschu...@adobe.com wrote:

 ...


 The SVG WG would like to start using the 'Path' object for its objects as
 well. We'd like this to be a generic object that can be used by other parts
 of the web platform.
 It would be strange to require a canvas context just to create pathh.


 I'd like to again say I don't think this thing should be called Path. Lots
 of other things have Paths, like maps, file systems, urls, why does the
 drawing one get to take the global namespace?

 Given that there's a bunch of new objects with Drawing as the prefix, I
 think we should name this DrawingPath like DrawingStyle and friends.

 No.

Then I object to us shipping this in Chrome. Bleeding on the global scope
with such a generic name ignoring all the other reasonable uses of the word
Path is not good for the platform. It's not forward thinking, and it's
confusing for developers.

Why is your one use case more important than FilePath, URLPath and MapPath?
Why do all the other APIs get prefixes and yours doesn't?
- E

Re: [whatwg] Questions regarding Path object

[Elliott Sprehn]

On Mon, Nov 11, 2013 at 3:59 PM, Dirk Schulze dschu...@adobe.com wrote:


 On Nov 12, 2013, at 7:19 AM, Elliott Sprehn espr...@chromium.org wrote:

  On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze dschu...@adobe.com
 wrote:
 
  ...
 
 
  The SVG WG would like to start using the 'Path' object for its objects
 as
  well. We'd like this to be a generic object that can be used by other
 parts
  of the web platform.
  It would be strange to require a canvas context just to create pathh.
 
 
  I'd like to again say I don't think this thing should be called Path.
 Lots
  of other things have Paths, like maps, file systems, urls, why does
 the
  drawing one get to take the global namespace?
 
  Given that there's a bunch of new objects with Drawing as the prefix, I
  think we should name this DrawingPath like DrawingStyle and friends.
 
  No.
 
  Then I object to us shipping this in Chrome. Bleeding on the global scope
  with such a generic name ignoring all the other reasonable uses of the
 word
  Path is not good for the platform. It's not forward thinking, and it's
  confusing for developers.

 No one is stopping you from objecting to ship it in Blink. I personally do
 not see any reason to diverge the web platform just because “Path” is a
 term that is also be used within the string “FilePath” or “URLPath. It
 seems rather obscure to add such a relation, since it is widely excepted
 that a path is a geometry if it doesn’t have a prefix that indicates
 otherwise.


I don't think that's true at all. If you asked random web developers what
they think of when they hear path, they likely think of the URL path (or
associated file system path to the resource they loaded). Path being a
geometry concept is pretty obscure by comparison. I even polled several
developers over here (and at other companies) and all of them said that had
they seen new Path() in a web app they would have assumed it was related
to the URL.

The naming topic was discussed too many times already and we always came
 back to Path. Safari on iOS and Mavericks ships with Path as well now. So
 it is your decision to block progress on the web platform or just stick to
 the naming.


That's unfortunate, but given that no other browser has shipped this that
seems like more than enough time to change things.

- E

Re: [whatwg] Avoiding synchronous iframe load

[Elliott Sprehn]

Note that loads can never be fully async, you'd break tons of content.
Navigating to about:blank is synchronous.

frame = document.createElement('iframe');
document.body.appendChild(frame);
frame.contentDocument; // synchronously available

Also javascript: URLs are not async in Firefox:

frame = document.createElement('iframe');
frame.src = 'javascript:alert(1);'
document.body.appendChild(frame);
alert(2);

This alerts 1 and then 2.

Presumably all this behavior is required by spec. If it wasn't then we
should fix the spec since not having that behavior would break nearly ever
major web app.


On Tue, Oct 15, 2013 at 7:02 PM, Ryosuke Niwa rn...@apple.com wrote:

 Hi,

 I'm trying to make page loads on iframe always asynchronous in WebKit.
  However, the current specification appears to indicate that the navigation
 happens synchronously.

 Namely, in the following example, the first alert should be true as far
 as I read the specification.

 script var a = false; /script
 iframe src=javascript:a=true onload=a = true/iframe
 script alert(a); /* or even setTimeout(function(){alert(a);},0); */
 setTimeout(function(){alert(a);},10) /script

 On the other hand, Firefox and Internet Explorer do not synchronously load
 iframes, and the first alert in the example above yields false although
 it yields true on WebKit and Blink.

 Am I reading the specification wrong/missing something?  If not, could you
 amend the specification to make page loads on an iframe always asynchronous?

 - R. Niwa

Re: [whatwg] Should video controls generate click events?

[Elliott Sprehn]

On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson i...@hixie.ch wrote:

 On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
 
  In a discussion about a click to play/pause feature for Opera on
  Android, the issue of click event handlers came up.[1] The problem is
  that pages can do things like this:
 
  ...

 I've made the spec say this is a valid (and recommended) implemenation
 strategy.


This means that if I have video controls on the page and then I click
something that shows a non-modal dialog that should dismiss on clicking
elsewhere in the page, and then click the video the page popup doesn't
disappear.

Should authors be listening for mouseup instead to take actions when users
click inside video?

- E

Re: [whatwg] Should video controls generate click events?

[Elliott Sprehn]

On Thu, Aug 22, 2013 at 10:03 AM, Elliott Sprehn espr...@chromium.orgwrote:


 On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson i...@hixie.ch wrote:

 On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
 
  In a discussion about a click to play/pause feature for Opera on
  Android, the issue of click event handlers came up.[1] The problem is
  that pages can do things like this:
 
  ...

 I've made the spec say this is a valid (and recommended) implemenation
 strategy.


 This means that if I have video controls on the page and then I click
 something that shows a non-modal dialog that should dismiss on clicking
 elsewhere in the page, and then click the video the page popup doesn't
 disappear.

 Should authors be listening for mouseup instead to take actions when users
 click inside video?


I see now that even this isn't possible:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attr-media-controls


If the user agent exposes a user interface to the user by displaying
controls over the media element, then the user agent should suppress any
user interaction events while the user agent is interacting with this
interface. (For example, if the user clicks on a video's playback control,
mousedown events and so forth would not simultaneously be fired at elements
on the page.)


This is wrong, it means I have no way to tell if you click inside the
video to dismiss popups or notifications. I don't think we should be
making video controls a blackhole to events, it breaks lots of use cases.

Instead we should expose the controls as a pseudo element on the event,
just like TransitionEvent has a String pseudoElement so you can tell if the
thing transitioning is the ::before or the ::after, we should add
::controls and inside the click handler you can take no action if the
target is the controls. If we assume the new Shadow DOM spec, we could just
use the part feature which was designed specifically for this kind of
thing and should be exposed on all events.

(User agents don't need to actually allow styling using the ::controls
pseudo element)

I already raised a bug about adding this to all MouseEvents specifically to
handle cases like this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22569

- E

Re: [whatwg] Comments on dialog

[Elliott Sprehn]

On Wed, Aug 21, 2013 at 3:58 PM, Ian Hickson i...@hixie.ch wrote:

 ...

   It's true that for seamless iframes we could change that, but the
   usual use case for seamless iframes is something like blog comments,
   so it's not clear that there's a use case for dialogs there. If there
   was to be one, we could consider it. It sounds like a lot of work to
   do if there's not a compelling need though.
 
  Hm, I was given to understand that it *was* intended that dialogs be
  able to escape iframes through some mechanism.

 That isn't specced currently. I'm not 100% I understand how it would work
 (I guess it would need a lot of infrastructure from CSS?), but I'm happy
 to do it if there's demand and if the CSS side is figured out.


Matt and I discussed this and I don't think we need it anymore. I've also
discussed it with security folks and they're not super comfortable allowing
a nested iframe to show arbitrary content over the main frame. Specifically
this gives non-sandboxes iframes superpowers they didn't have before (so
we'd need a special new attribute) and we'd need to show info bars to
notify the user of the origin of the dialog... even then it's scary because
the content seen under the ::backdrop is from a different origin than the
dialog itself.

- E

Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)

[Elliott Sprehn]

Can we just add a new event that takes an event object instead of a huge
list of arguments? :)


On Fri, Jul 12, 2013 at 11:30 AM, James Greene james.m.gre...@gmail.comwrote:

 I'd rather get an Error-like duck-typed object with this shell info for
 cross-domain requests than to not get a real Error object when the
 unhandled error *is* from the same origin.

 Adding the trace as another new argument to `window.onerror` is certainly
 an option but the parameter list is getting long and I suspect that Error
 prototypes may still gain additional properties in the future.  Continuing
 down this path of adding more parameters rather than just passing an Error
 instance or Error-like object (or providing a separate supplemental method
 like `window.getLastError()` seems like one of those decisions that might
 results in infinite sadness in the future.

 Sincerely,
 James Greene



 On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters sim...@opera.com wrote:

 On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn espr...@chromium.org
 wrote:

  On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt oli...@apple.com wrote:

  ...
 That's tricky - what is your stack trace?  You can very easily end up
 leaking private information across frames.


  window.onerror is triggered across non-same origin frames?


 Yes, but always with these arguments:

 Script error., , 0, 0

 --
 Simon Pieters
 Opera Software

Re: [whatwg] HTML: A DOM attribute that returns the language of a node

[Elliott Sprehn]

On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil pocci...@gmail.com wrote:


 I have no objection to the name baseLang rather than language as the
 name of the DOM attribute.

 But if there isn't more interest or you decide not to add this DOM
 attribute, I encourage you to at least:


fwiw WebKit (and Blink) implement this through CSS inheritance since you
need to know the lang for all kinds of things and walking up the DOM
repeatedly would be expensive.

-webkit-locale is inherited by default and contains the enclosing @lang
value. You can query it through getComputedStyle(node).webkitLocale. That
doesn't help your custom parser though.

- E

Re: [whatwg] HTML: A DOM attribute that returns the language of a node

[Elliott Sprehn]

On Wed, May 1, 2013 at 1:49 AM, Robert O'Callahan rob...@ocallahan.orgwrote:

 On Wed, May 1, 2013 at 8:01 PM, Elliott Sprehn espr...@chromium.orgwrote:

 fwiw WebKit (and Blink) implement this through CSS inheritance since you
 need to know the lang for all kinds of things and walking up the DOM
 repeatedly would be expensive.

 -webkit-locale is inherited by default and contains the enclosing @lang
 value. You can query it through getComputedStyle(node).webkitLocale. That
 doesn't help your custom parser though.


 Interesting. What does body:lang(en) { -webkit-locale:fr; } do? :-)


Nothing sensible. :) We still walk up the tree when doing selector
matching, but you'll confuse some render tree operations. Looking through
the code again we don't use -webkit-locale as much as I thought, though
perhaps we should and prevent user CSS from tampering with it.

- E

Re: [whatwg] Polling APIs in JavaScript vs Callbacks

[Elliott Sprehn]

On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith dhtmlkitc...@gmail.comwrote:

 On 2/9/13, Glenn Maynard gl...@zewt.org wrote:
  On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
  jackalm...@gmail.comwrote:
 
  That said, there *are* still some isolated use-cases for polling.  ^_^
   When an event-based approach would potentially deliver far too many
  events, with separation between them perhaps less than 1ms, exposing a
  polling-based API instead can be useful.  I haven't followed the
  Gamepad API lately, but I know this was at least considered for some
  of the types of feedback, such as the exact position of joysticks or
  pressure on buttons, both of which can change very rapidly in
  realistic scenarios.
 
 
  A polling API doesn't help you there, since you can't poll every 1ms in
  script (certainly not in the UI thread, and probably not reliably even
 in a
  worker).  In fact, since setTimeout will be throttled but events fired by
  the browser don't have to be, events can be sent faster than you can poll
  in the UI thread (though this is probably a bad idea most of the time).
 
  The solution is probably a matter of buffering the changes, and limiting
  how frequently something was buffered events fire.
 Are you proposing event quantization threshold?


There's no reason to have a threshold. We should just batch and deliver at
checkpoints like end-of-microtask (MutationObserver) or rAf (Animations).

- E

Re: [whatwg] Polling APIs in JavaScript vs Callbacks

[Elliott Sprehn]

On Sat, Feb 9, 2013 at 8:43 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard gl...@zewt.org wrote:
  This is just to say: callbacks are the pattern on on the platform, not
  polling, and WebGL should follow that pattern, not go its own way and
 make
  up its own conventions.  If people don't understand why the platform's
  conventions are what they are, and think they should be something else,
  please encourage them to come here and discuss it--not to try to make
 WebGL
  its own isolated island.  That's damaging to WebGL and the platform as a
  whole.

 Completely correct, and I agree.

 That said, there *are* still some isolated use-cases for polling.  ^_^
  When an event-based approach would potentially deliver far too many
 events, with separation between them perhaps less than 1ms, exposing a
 polling-based API instead can be useful.


I disagree, there's no reasonable reason for polling. If the events would
fire too frequently then the API should be designed to batch up the
notifications and fire at specific checkpoints like rAf or end of micro
task.

There's no reason to poll on the web.

- E

Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)

[Elliott Sprehn]

On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt oli...@apple.com wrote:

 ...
 That's tricky - what is your stack trace?  You can very easily end up
 leaking private information across frames.


window.onerror is triggered across non-same origin frames?

- E

Re: [whatwg] [Notifications] Constructor should not have side effects

[Elliott Sprehn]

On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald jaffathec...@gmail.comwrote:

 On 29 January 2013 05:36, Charles McCathie Nevile cha...@yandex-team.ru
 wrote:
  Exactly. And if we designed XMLHttpRequest from scratch it would have
 them
  too.
 
  Really? This doesn't seem like a good idea, so I'd be interested to know
  why. Is there an explanation laid out somewhere?

 Why doesn't it seem like a good idea? Is there a use-case for creating
 a Notification/XMLHttpRequest/WebSocket/EventSource without performing
 their action?


Yes, because decoupling allocating from action lets you preallocate objects
to perform a task in advance of executing the task. It lets you structure
your code without having to worry about when something executes, and it
lets you inspect the object in the web inspector without having the verb
execute first.

For example you can do var request = new XMLHttp(  ) at the start of a
function, but then later decide you didn't want to send the request, and
never call send(). It also lets you create clean abstractions and layers so
one library may create the notification, but another one may eventually
show it. With notifications I can't look at the properties of a
notification in the web inspector without having it show on me...

Constructors are not verbs. new Notification doesn't mean show, and new
XMLHttpRequest doesn't mean send.

This is pretty standard OO best practices stuff.
ex.
http://www.beaconhill.com/solutions/kb/java/code-in-constructor-anti-pattern.html

- E

Re: [whatwg] [Notifications] Constructor should not have side effects

[Elliott Sprehn]

On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote:

 ...
 Is that even a valid use case? It seems dubious to instantiate a class
 named request and then not send a request.


You can't go down that line of thinking because it doesn't generalize. For
instance why would I instantiate a class named node without putting it
into the tree? If we followed that logic then new HTMLDivElement should
append itself into the document by default.

- E

Re: [whatwg] [Notifications] Constructor should not have side effects

[Elliott Sprehn]

On Tue, Jan 29, 2013 at 3:32 PM, Ian Hickson i...@hixie.ch wrote:

 On Tue, 29 Jan 2013, Elliott Sprehn wrote:
  On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa rn...@apple.com wrote:
  
   ... Is that even a valid use case? It seems dubious to instantiate a
   class named request and then not send a request.
 
  You can't go down that line of thinking because it doesn't generalize.
  For instance why would I instantiate a class named node without
  putting it into the tree?

 There are all kinds of reasons why you may do this. Hence, we support it.

 Reasoning by use case definitely generalises -- it's how we design
 everything around here. :-)


But reasoning by naming certainly doesn't. His comment was about creating a
class named request.

Re: [whatwg] Proposal: HTMLCanvasElement.printCallback API

[Elliott Sprehn]

On Mon, Jan 28, 2013 at 6:02 PM, Robert O'Callahan rob...@ocallahan.orgwrote:

 On Mon, Jan 28, 2013 at 6:25 PM, Elliott Sprehn espr...@gmail.com wrote:

 3) If we're advocating that developers put a canvas on every page that
 covers the whole page as the standard way to handle large document
 printing why not have a handler that gets given a canvas for every page
 automatically instead of requiring the developer to insert it themselves.


 Another use-case is when you have a document that's regular HTML and just
 happens to contain one or more canvas images that should be beautiful
 when printed.


Why can't I do this for video or object or any number of other things
then? All those things want to be beautiful when printed too. :)

In that world I really think we want something closer to
Element#printCallback.


 4) SVG is for vector graphics, not canvas. Why can't I replace an entire
 page with an svg instead of drawing to a canvas? :)


 SVG doesn't fit some use-cases very well, for example, when you generate
 graphics from some underlying (large) data model.


Vector graphics is exactly what you want when the data model is really big
though since it lets you prune out things you know can't be seen and stream
the commands directly to hardware without rasterization as they're
attempting to do with canvas magic in this proposal.

If SVG is broken for this use case we should fix that, it seems really sad
to give up on SVG and bolt vector graphics onto canvas.

- E

Re: [whatwg] Proposal: HTMLCanvasElement.printCallback API

[Elliott Sprehn]

1) I feel like this should probably be an event. I don't know why we're
inventing new callback facilities everywhere.

canvas.onprintcanvas = function(e) { e.printState ... }

2) What does send the canvas' content without rasterization to the
printer mean? How are blending and overlapping images handled? Your
current description makes it sound like if I did two drawImage() calls it
would make my printer print the images on top of each other.

3) If we're advocating that developers put a canvas on every page that
covers the whole page as the standard way to handle large document
printing why not have a handler that gets given a canvas for every page
automatically instead of requiring the developer to insert it themselves.
This seems much easier, and handles the memory management for since we can
drop the backing buffer between events for each page.

document.onprintpage = function(e) {
  e.index // number of the page
  e.range // range that encompasses all the nodes to print
  e.canvas // canvas to send drawing commands to for printing
};

4) SVG is for vector graphics, not canvas. Why can't I replace an entire
page with an svg instead of drawing to a canvas? :)

- E


On Wed, Jan 23, 2013 at 3:11 PM, Julian Viereck 
julian.vier...@googlemail.com wrote:

 Discussing the proposal with Robert roc O'Callahan, we came up with the
 following adjustments. They are targeting the Some more details on the
 behavior of the API from before:

 (1) With the previous proposal, printCallbacks are executed even after the
 window is unloaded. We think this is not a good idea. There shouldn't be
 any JavaScript execution after a window is unloaded. Therefore let's add
 the following:

 Encourage the UA to prevent closing the window while print callbacks
 are pending. If the window is nevertheless closed and while some
 printCallbacks have not completed yet, all printCallbacks are canceled, the
 JavaScript execution is stopped and the print job is aborted. Canceling the
 printCallbacks is done to prevent any JavaScript execution after the window
 is unloaded.


 (2) Given the change in (1), we can now change the following point:

  * the canvas property on the printContext points to the canvas on the
 page and not the canvas element that is printed. Otherwise it's possible to
 change the layout of the printing while printing. As the canvas on the page
 might not be available anymore (e.g. the canvas was removed and garbage
 collected from the document before the printCallback gets invoked), the
 canvas property might be undefined or null.


 to:

 * the canvas property on the printContext points to the canvas on the
 page and not the canvas element that is printed. Otherwise it's possible to
 change the layout of the printing while printing.

 Simply saying, if the window object is always alive while the
 printCallbacks are happening (thanks to (1)), the canvas property on the
 printContext can always point to the canvas on the page.

 Best regards,

 Julian

 On 9/26/12 2:46 PM, Julian Viereck wrote:

 Hello WHATWG members,

 This email is about proposing a new attribute printCallback on the
 HTMLCanvasElement (in the following called Canvas). This new API allows
 to:

 * define the content of a canvas element during the printing progress
 * send the canvas' content without rasterization to the printer

 The basic API was implemented in [1] and is available in Firefox Nightly
 18.

 ## Motivation And Use-Case

 The motivation for designing and implementing the API was to add proper
 printing support for the PDF.JS project. The PDF.JS project is an
 implementation of aPDF viewer using only web technologies. Without this API
 it is not possible to:

 * render only the pages needed for printing. A webpage is printed with
 the content visible at the moment the print action is started. For PDF.JS
 this means that all pages are required to be rendered before printing.
 Rendering all the pages takes quite some time for complex and huge
 documents ( 100 pages). But the user might only want to print the first
 page. That means, the user waits for unnecessary computation to finish.
 * print the content of a canvas element without rasterization artifacts
 on the printout. One could increase the size of the canvas such that the
 rasterization doesn't becomes visible, but this is not possible due to the
 large usage of memory going with this. Using a different way to render the
 pages than using canvas (e.g. SVG) is not possible, due to memory and
 performance issues.

 Although not directly relevant to PDF.JS - it's also not possible to

 * define the content of a printed page that looks exactly the same cross
 all user agents. There are small variations, that cause breaks and styles
 to look slightly different between user agents. Using CSS it's possible to
 make one canvas element take up one physical page and then precisely layout
 contenton the canvas.

 (I will later describe briefly how the API was used to solve these
 

Re: [whatwg] Feedback on Web Worker specification

[Elliott Sprehn]

On Tue, Nov 20, 2012 at 6:30 PM, Ian Hickson i...@hixie.ch wrote:

 ...
 On Sat, 3 Nov 2012, Fred Andrews wrote:
 
  Feedback and suggestions for appropriate markup to declare web workers
  would be appreciated.

 Workers are only usable from script, so just start them in script. No need
 for anything declarative.


This has come up a couple times with developers and I think being able to
do:

script type=worker id=taskQueue
  ...
/script

and then being able to access the worker to post message it by id would be
extremely useful.

document.getElementById('taskQueue').worker.postMessage(...);

Forcing the code into a separate file or requiring a data URL is annoying.

- E

Re: [whatwg] Improving autocomplete

[Elliott Sprehn]

On Sat, Nov 10, 2012 at 10:50 PM, Maciej Stachowiak m...@apple.com wrote:


 (1) If this API fills in a form completely based on stored data, and not
 by completing the user's typing, then it is autofill rather than
 autocomplete.


Yes, we considered requestAutofill() but it seems rather confusing since
the attribute on the form is autocomplete. Perhaps we should revisit this.


 (2) If this API provides the ability to get user information without even
 having a visible form, then it's not clear that it is even really autofill.
 It's just requestUserInformation() or something.


It doesn't provide such a feature. A form is _always_ displayed. Think of
this like a fancy async prompt().



 (3) This API has important privacy and even security considerations. You
 have to tell the user exactly what you are going to fill in to the site
 before they approve. Unfortunately, most won't read it. If sites are asking
 for so much info that they have to split pages for usability, then it seems
 likely the UI that tells the user what the site is asking for will be
 impractical for most users to meaningfully review.


We don't believe this is the case. Think of an airline website: the last
step is going to ask you to review all your information, but you still had
to enter it across multiple steps. This is done for lots of reasons that
have to do with  optimizing click through. The goal is to avoid scaring the
user by making it look like they need to fill out tons of inputs.

Mobile is particularly egregious where we've seen one page worth of
information that's easy to review split across many different pages to
optimize the form completion rate.

 This becomes especially dangerous if the mechanism can fill in credit card
 info. I would be very nervous if the browser could at any moment pop up a
 dialog that would submit all my credit card info to a dubious site if I
 slip and click the wrong button. Can you expand more on what thought you
 have given to the security considerations?


It requires a user gesture and is connected to the browser chrome. At the
limit this dialog could even show a per domain security image or require a
pin, though I don't think it's reasonable for the standard to require that
level of protection.

Ultimately protections against accidental clicks are up to the browser
vendor. You can slip and click and accidentally expose your location
information through navigator.geolocation's dialog as well, it's up to the
browser vendor to decide how to show the UI to prevent that.


 (4) Should this API be limited to initiation during a user interaction?
 That would reduce the ability of sites to spam the user with such forms.


Indeed, a user gesture should be required to launch the UI.


 (5) What makes the UI unspoofable? Is that an important part of the
 security model?


It overlaps/is connected to the browser chrome.

- E

Re: [whatwg] Improving autocomplete

[Elliott Sprehn]

On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth w...@adambarth.com wrote:
  When should the UA offer to fill in the form (e.g., to select which
  address they would like to use for shipping this particular order)?

 Presumably on page load.


It was our experience that making this judgement call is difficult, and
giving authors control is better than guessing. There's also technical
issues such as dynamically created forms when using page load, or our
primary use case which is hidden forms and a button that launches this UI
which is very attractive on mobile.

So to answer your original question about use cases, we want to make it
easy for an author to declaratively describe a data set and then request
the information from the browser. Using this we want to make it trivial,
especially on mobile, to request the information from the UA to allow
faster form filling experiences (ex. shipping forms, payment forms, login
forms, etc.)


  In particular, Elliott wrote:
 
  Authors can also display
  no forms at all to users of a browser who implements this proposal for
  one click checkout experiences which are important on mobile devices.

 I guess in that case it would be nice to know the user agent actually
 did display some UI.


Indeed, if the browser is incapable of displaying a UI we should fire an
error event.

Are we using cancel elsewhere by the way? Fullscreen uses error as
 suffix for the event type.


That's a great idea, I've unified the naming with fullscreen.

- E

Re: [whatwg] Should scrollbars move focus?

[Elliott Sprehn]

On Mon, Oct 22, 2012 at 6:28 PM, Ojan Vafai o...@chromium.org wrote:
 ...

 This doesn't have to be specced, but it also doesn't really seems to be a
 platform convention issue. The platforms that have scrollbars are all the
 same (i.e. clicking on the scrollbar never moves focus) and no browser
 fuller matches platform that convention. Gecko's behavior is most consistent
 with that, except Gecko *does* move focus if you click on a textarea
 scrollbar. It seems especially bad that you get a different behavior if you
 click on the scrollbar of the window vs. the scrollbar of an overflow:auto
 element that fills the window

So what's the consensus here? Should WebKit have Gecko's behavior?
Should we unify the world and make scrollbars never move focus even on
textarea? :)

- E

[whatwg] Should scrollbars move focus?

[Elliott Sprehn]

I was working on a bug [1][2] recently where authors had complained
about WebKit's behavior where clicking a scrollbar unfocuses the
activeElement. What's particularly quirky is that the window scrollbar
never moves focus in any browser I tried, but overflow scrollbars
inside the page *do* move focus in WebKit, IE and Opera but not in
Gecko.

This behavior seems unfortunate because it means scrolling a form
inside an overflow div moves focus from where you were typing and it's
also really weird that window scrollbars are special.

What's the correct behavior here? It would be best if all the browsers
could be consistent, but I'm not sure the existing common behavior is
best. :)

[1] https://bugs.webkit.org/show_bug.cgi?id=96335
[2] http://code.google.com/p/chromium/issues/detail?id=51469

- Elliott

Re: [whatwg] [canvas] Path object

[Elliott Sprehn]

What of the fact that this breaks existing pages with input
id=Path that access it as just Path? Historically this has been a
non-starter for new APIs.

On Tue, Oct 2, 2012 at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn espr...@gmail.com wrote:
 I was looking at the canvas Path API and had some concerns. In
 particular it's inconsistent with the rest of canvas:

 We already have CanvasGradient and CanvasPattern in the global
 namespace, so this should probably be called CanvasPath.

 We also have createLinearGradient() and createPattern(), but this new
 thing is new Path.

 Could we get some consistency here? Like adding new CanvasGradient()
 (or a createPath() method) to match up with Path and renaming this
 thing CanvasPath?

 I think the SVGWG would be opposed to that - we rather like the Path
 api and would appreciate being able to appropriate it for our own uses
 (merging with the path API).

 I'm fine with gradients/patterns moving to a plain constructor rather
 than a factory method, though.

 ~TJ

Re: [whatwg] [canvas] Path object

[Elliott Sprehn]

On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@gmail.com wrote:
  What of the fact that this breaks existing pages with input
  id=Path that access it as just Path? Historically this has been a
  non-starter for new APIs.


 Surely it's not a non-starter in general, or else no new APIs could ever be
 added to the platform--at worst it just means picking a less generic name.
 I assume that's not strictly needed; URL must be a more common ID than
 Path.  (Path makes me think of URL paths, though.  Something like
 DrawPath would be a little clearer.)

What about unifying all of these as:

new GraphicsPath()
new GraphicsLinearGradient()
new GraphicsRadialGradient()
new GraphicsPattern()

and fixing HTML5 canvas to support these new constructors instead?

I'm a little surprised about the window.URL change that went through
recently. There must be tons of input id=URL's around, and lots of
old form generating code accessed them through window.id.

@hixie: How was it decided that this wasn't going to break the web?

- E

Re: [whatwg] DOM4: createHTMLDocument argument

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 1:23 AM, Simon Pieters sim...@opera.com wrote:
 ...

 The title element is required in HTML. What are the use cases for creating a
 document without a title?


It's not required for iframe srcdoc (or HTML in email, ...) so if
you were building a document to then serialize to assign as a srcdoc
you might want to omit it.

- E

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 ...

 The paragraph and span concept in SVG
 wouldn't be the same thing so it's not an antipattern. You would have
 to specify some kind of x/y coordinate and the width since SVG doesn't
 have a flow concept so there would be nothing to size or place
 against.

 No, all you have to do is define SVG positioning as being a slight
 diff from absolute positioning.  Then all the sizing just falls out.

Can you explain this? I don't understand how we decide the width of an
html element as the containing block is the svg element. Are you
saying we default to shrink wrap? Also, how does your proposal address
flowing text inside of a path?

A strawman of the JSON spec rewritten with your proposal would be useful.

- E

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Sep 11, 2012 11:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn espr...@gmail.com
wrote:
  On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
  ...
  Also, how does your proposal address
  flowing text inside of a path?

 That's a good question!  Presumably you mean that, for example, one
 might want to have emphasized text in a text-along-a-path flow?  I
 suppose it should be as easy as making them children of a textPath,
 and setting display:svg to make them obey SVG rendering rules rather
 than the CSS box model.

I mean if you look at the svg flow spec there's an example of text inside a
polygon or even text flowing inside of large bubble letters.

Similar concept as CSS exclusions, but it doesn't make sense to specify the
polygon twice to use that.


  A strawman of the JSON spec rewritten with your proposal would be
useful.

 I don't understand this request.


Sorry its not the JSON spec, it just had a similar theme (my confusion). I
meant could you rewrite the railroad svg from your original email to show
how this is better?

http://www.xanthir.com/etc/railroad-diagrams/example.html

- E

Re: [whatwg] Using SVG instead of Canvas for extensions

[Elliott Sprehn]

SVG taints the canvas in every browser I've tried which precludes many uses
of canvas that require toDataURL() to work.

I don't think SVG is a reasonable solution to the lacking features in the
canvas API. Having to decide between bit level access and dotted lines is
not reasonable.

On Sat, Jan 14, 2012 at 12:35 PM, Charles Pritchard ch...@jumis.com wrote:

 There have been quite a few threads and requests for extensions to the
 Canvas 2d API.

 I've been working on some extensions to help Canvas authors meet WCAG2
 conformance, over at public-canvas-api.

 I want to point out to all of you, that many of the features you'd like to
 see in Canvas can be accomplished via drawImage and SVG.
 SVG support in the image element is working in many browsers.

 There are many methods available in SVG that are not available in Canvas.
 Use SVG images as a means to enable them in your Canvas interface.
 It's not a perfect solution, but for some things, like dotted lines, it
 can work out.

Re: [whatwg] Using SVG instead of Canvas for extensions

[Elliott Sprehn]

On Wed, Jan 18, 2012 at 7:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote:

 On Thu, Jan 19, 2012 at 4:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:

  Whether other UAs can fix this bug on their end faster than they can add
  various canvas APIs is an interesting discussion, I suppose.
 

 Of course it's vastly better for the Web platform for browsers to fix their
 bugs than add new APIs to work around the bugs :-)


I completely agree and it's good to see Gecko has fixed this, we'll have to
see what happens in Webkit though. Last I talked with Adam Barth early last
year there were still security concerns with allowing SVG images to render
to a canvas without tainting it.

Gecko completely punts rendering foreignObject to a canvas while Webkit
will let you do fun things like render a browser native control (ex.
button) to a canvas by embedding it into SVG.

I suppose the presence of foreignObject could taint it, though at some
point we should work out the issue of rendering same domain HTML this way.

- E