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
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
On Sep 5, 2015 10:20 AM, "Anne van Kesteren" wrote:
>
> I emailed some folks individually, but I suppose I should also make a
> note here. At least Chrome, Firefox, and Safari have extended the HTML
> parser beyond the HTML Standard with the addition of special parsing
> rules for and elements.
On Sat, Jul 11, 2015 at 11:40 PM, Anne van Kesteren
wrote:
> On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers 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
On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking wrote:
>
> ...
>
> I agree 100% with this principle. Changed mayCancel to default to false:
>
> https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140
> .
>
On Wed, Jun 24, 2015 at 3:30 PM, Barry Smith 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 element with
> a
> javascript file embedded inside, like this:
>
>
>
>
>
> and the javascript
On Tue, Jun 16, 2015 at 2:33 PM, Tab Atkins Jr.
wrote:
> On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn
> wrote:
> > On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr.
> > wrote:
> >> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn
> >> wrote:
> >>
On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr.
wrote:
> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn
> wrote:
> > sizes is a generic feature that's available for all image resources.
>
> No it's not; and are completely unrelated.
>
>
On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor 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?
On Tue, Jun 16, 2015 at 12:43 PM, Maciej Stachowiak wrote:
>
> > On Jun 15, 2015, at 5:40 PM, Justin Dolske 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
Adding a whole new attribute for this seems like overkill, why not use the
rel.
That's what the rel list was designed for.
On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor
wrote:
> When is used to pull in external resources, authors may use
> several attributes as hints about the linked res
On Tue, May 19, 2015 at 2:02 PM, Jonas Sicking wrote:
> On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola 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?
>
What of the many things in that email are you considering?
On Mon, May 18, 2015 at 3:49 PM, Domenic Denicola 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 [mai
On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky 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 lowerca
On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad 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 documen
On Tue, Feb 24, 2015 at 12:34 AM, Tab Atkins Jr.
wrote:
> On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa wrote:
> >> On Feb 23, 2015, at 5:40 PM, Dean Jackson wrote:
> >> At the recent Houdini meeting there was a vague agreement between the
> browser engines on adding a way for elements to be no
On Thu, Jan 8, 2015 at 3:38 AM, Rob Wu 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 us
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 wrote:
>
>
> On 10/12/14, 3:45 AM, "Silvia Pfeiffer" wrote:
>
> >Hi all,
> >
> >In the Inband Text Tracks Community Group we've recently ha
This is what the attached and detached callbacks are for on custom
elements. Someone can build an 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, develope
On Tue, Jul 8, 2014 at 7:37 AM, Brian Blakely
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
On Tue, May 13, 2014 at 11:21 AM, Ian Hickson 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
> > contentEdit
On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert wrote:
> On 01/23/2014 03:16 AM, Stewart Brodie wrote:
> >> [2] I only noticed one rendering difference -- IE11 honors "border" on
> >> , unlike the other browsers that I tested. (It still doesn't honor
> >> e.g. "display"/"width"/"height", though.)
On Wed, Dec 18, 2013 at 4:58 PM, Brian Blakely wrote:
> On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson wrote:
>
> > On Wed, 18 Dec 2013, Brian Blakely wrote:
> > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson wrote:
> > > >
> > > > I've added a rule to the spec that says that viewports have to be
On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking 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 defaul
On Monday, November 18, 2013, Rik Cabanier wrote:
>
>
>
> On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan
>
> > wrote:
>
>> On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski <
>> jussi.kallioko...@gmail.com > 'jussi.kallioko...@gmail.com');>> wrote:
>>
>>> Path is also too generic even in t
On Mon, Nov 11, 2013 at 3:59 PM, Dirk Schulze wrote:
>
> On Nov 12, 2013, at 7:19 AM, Elliott Sprehn wrote:
>
> > On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze
> wrote:
> >
> >> ...
> >>
> >>
> >> The SVG WG would like to start using
On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze 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
On Mon, Nov 4, 2013 at 9:14 AM, Rik Cabanier wrote:
> On Mon, Nov 4, 2013 at 2:07 AM, Jürg Lehni 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
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 = d
On Thu, Aug 22, 2013 at 10:03 AM, Elliott Sprehn wrote:
>
> On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson wrote:
>
>> On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
>> >
>> > In a discussion about a "click to play/pause" feature for Opera on
>> >
On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson 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:
> >
> > .
On Wed, Aug 21, 2013 at 3:58 PM, Ian Hickson 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 b
Sincerely,
> James Greene
>
>
>
> On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters wrote:
>
>> On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn
>> wrote:
>>
>> On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt wrote:
>>>
>>> ...
>>>
On Wed, May 1, 2013 at 1:49 AM, Robert O'Callahan wrote:
> On Wed, May 1, 2013 at 8:01 PM, Elliott Sprehn wrote:
>
>> 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
>>
On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil 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
On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith wrote:
> On 2/9/13, Glenn Maynard wrote:
> > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> > wrote:
> >
> >> That said, there *are* still some isolated use-cases for polling. ^_^
> >> When an event-based approach would potentially deliver far
On Sat, Feb 9, 2013 at 8:43 AM, Tab Atkins Jr. wrote:
> On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard 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
On Thu, Feb 7, 2013 at 12:38 AM, Julian Viereck <
julian.vier...@googlemail.com> wrote:
> On 1/28/13 6:25 AM, Elliott Sprehn wrote:
>
>> 1) I feel like this should probably be an event. I don't know why we're
>> inventing new callback facilities everywhere.
>&
On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt 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
On Tue, Jan 29, 2013 at 3:32 PM, Ian Hickson wrote:
> On Tue, 29 Jan 2013, Elliott Sprehn wrote:
> > On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa wrote:
> > >
> > > ... Is that even a valid use case? It seems dubious to instantiate a
> > > class named &
On Tue, Jan 29, 2013 at 3:02 PM, Ryosuke Niwa 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 clas
On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald wrote:
> On 29 January 2013 05:36, Charles McCathie Nevile
> 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
On Mon, Jan 28, 2013 at 6:02 PM, Robert O'Callahan wrote:
> On Mon, Jan 28, 2013 at 6:25 PM, Elliott Sprehn 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 lar
The Notification constructor should not have side effects. This is
generally considered bad design, and the rest of the platform doesn't have
this either.
Specifically new Notification() should not show the notification since it
prevents reuse of the notification after calling close(), and is surp
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
On Tue, Nov 20, 2012 at 6:30 PM, Ian Hickson 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 anythin
On Sat, Nov 10, 2012 at 10:50 PM, Maciej Stachowiak 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 sinc
On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren wrote:
> On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth 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
On Mon, Oct 22, 2012 at 6:28 PM, Ojan Vafai 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 match
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 foc
On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard wrote:
>> On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn wrote:
>> > What of the fact that this breaks existing pages with > > id="Path"> that access it as just Path? Historically this has been a
>> > non-st
What of the fact that this breaks existing pages with 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. wrote:
> On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn wrote:
>> I was looking at the canvas Pat
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
On Sep 11, 2012 11:35 AM, "Tab Atkins Jr." wrote:
>
> On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn
wrote:
> > On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr.
wrote:
> >> ...
> > Also, how does your proposal address
> > flowing text inside of a ?
On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. 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 nothin
On Tue, Sep 11, 2012 at 1:32 AM, Robin Berjon wrote:
> On 11/09/2012 10:15 , Elliott Sprehn wrote:
>>
>> ...
>
>> SVG has a totally different font and styling model, different kinds of
>> animations, filters, etc. The paragraph and span concept in SVG
>> would
On Tue, Sep 11, 2012 at 1:23 AM, Simon Pieters 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 (or HTML in email, ...) so if
you were building a document to then serialize to assign as a srcdoc
you
On Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn wrote:
> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. wrote:
>
>...
>>
>> Another solution could be SVG inventing their own elements for these
>> kinds of things. For example, #1 could be solved with an
>&g
On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. wrote:
> ...
>
> This would be a lot easier if I could somehow invoke the CSS box model
> inside of SVG, ...
This tightly binds the list of element names in SVG to HTML, and also
breaks assumptions inside SVG DOM that HTML5 may depend upon. Indeed
S
Browsers allow unescaped @'s already in the URL field. You can't hijack it
to mean something different like that.
On Sun, Jun 17, 2012 at 7:32 AM, Florent FAYOLLE <
florent.fayoll...@gmail.com> wrote:
> Hello,
>
> I have written a proposal that introduces a new way to include remote
> contents in
On Wed, Jan 18, 2012 at 7:25 PM, Robert O'Callahan wrote:
> On Thu, Jan 19, 2012 at 4:09 PM, Boris Zbarsky 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 fo
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 1
On Wed, Dec 21, 2011 at 3:25 PM, Boris Zbarsky wrote:
> On 12/21/11 6:19 PM, Elliott Sprehn wrote:
>>
>> This is
>> interesting because the documentation for almost standards mode states
>> that it only changes the way images are placed in tables.
>
>
> It ch
I recently stumbled upon an issue where it appears that limited quirks
mode (almost standards) and standards mode compute the size of
replaced content (iframes, objects, images) differently. This is
interesting because the documentation for almost standards mode states
that it only changes the way
64 matches
Mail list logo
