Re: [whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment

[Anne van Kesteren]

On Fri, Oct 25, 2019 at 10:59 AM 'David Bokan' via blink-dev
 wrote:
> The kind of feedback we received here would have been wonderful to have
> several weeks ago. What should we be doing to get to this step earlier?

For WHATWG, PRs against standards tend to help as they require review,
implementer commitments, and adequate test coverage. And editors will
provide guidance for all of those.

Re: [whatwg] rendering for case min == max

[Anne van Kesteren]

On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen
 wrote:
> The spec should specify one way or the other for this corner case.

Agreed, we're tracking this in
https://github.com/whatwg/html/issues/3520. If anyone would like to
help clarify the prose in the form of a pull request or wants to make
a strong case for Firefox's behavior, that'd be much appreciated.


-- 
https://annevankesteren.nl/

Re: [whatwg] [CSSWG][css-scroll-snap] Updated CR of CSS Scroll Snapping Level 1

[Anne van Kesteren]

On Mon, Dec 25, 2017 at 11:54 AM, fantasai
 wrote:
> A related concern was brought up that some DOM APIs define scrolling to
> an element in a way that conflicts with scroll-snapping; such APIs should
> allow for an element's snap position, if defined, to dictate the position
> of an element to the viewport if no explicit argument is given to the
> contrary.

The way I would expect this to work is that if CSS "owns" scrolling
(which I think it ought to), it defines an operation that performs
scrolling taking into account various parameters. Those DOM APIs then
call into that operation. Then if you define new properties that
affect scrolling, you only need to adjust the scrolling algorithm and
the various APIs will not require any changes as they all share the
same underlying primitive. I'd recommend figuring out that primitive
and clearly documenting it (parts of it are already in CSSOM View if I
remember correctly).


-- 
https://annevankesteren.nl/

[whatwg] Further working mode changes

[Anne van Kesteren]

Last week we made some further refinements to the way the WHATWG
operates and are pleased that as a result Microsoft now feels
comfortable to participate:

  https://blog.whatwg.org/working-mode-changes
  https://blog.whatwg.org/copyright-license-change

Let me also take this moment to remind everyone that most changes to
WHATWG standards are discussed exclusively on their GitHub
repositories (linked from the top of each standard). We also created
https://github.com/whatwg/meta to discuss things that don't really fit
anywhere else. If you want to partake in ongoing changes, either by
giving feedback or proposing your own in the form of a pull request,
GitHub is the place to be.

There are no plans to discontinue this mailing list; it'll continue to
mainly be used for announcements such as this one.


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Wed, Apr 19, 2017 at 9:55 PM, Yay295  wrote:
> Maybe a solution then would be to provide a way to request more storage
> space?

Sounds like it. At least in Firefox https://storage.spec.whatwg.org/
will provide that soonish, including the guarantee that the browser
won't remove your application data unless the user asks it to do so.

(This is why it's always good to start with use cases, examples, and
general problem descriptions, before delving into specific solutions
that may or may not solve the problem.)


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Wed, Apr 19, 2017 at 11:08 AM, duanyao  wrote:
> This is really not intended. I just don't quite understand some of those
> points. For example,
> Is "the web being fundamentally linked to HTTP" just the current status of
> the industry, or
> the inherent philosiphy of the web? If the latter, some explanation or
> document would be very
> appreciated.

I suspect it's actually a little higher-level than HTTP, with that
indeed being the current state, but the web is about the exchange of
data between computers and definitely sits at a higher level of
abstraction than the particulars of the Linux or Windows file system.
It's hard to define concretely I think, but being platform-independent
and having data addressable from anywhere are important principles.


> Doesn't file: protocol also abstract away much of the file system? What
> parts make it a bad abstraction?
> You mentioned casing and unicode normalization.

File URLs (it's not a protocol really) are still fundamentally tied to
the file system, including how it's hierarchical and such. And then
indeed there's all the legacy implications of file URLs.


> I'm not particularly eager to write access myself. Maybe we can seperately
> discuss read and write cases.

I already pointed to https://wicg.github.io/entries-api/ as a way to
get access to a directory of files and  as a way to
get access to a sequence of files. Both for read access. I haven't
seen any interest to go beyond that.


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Wed, Apr 19, 2017 at 5:45 AM, duanyao  wrote:
> These have been a lot of discussion on that in this thread. Do you think 
> writing a more formal document would be helpful?

Perhaps. Fundamentally, I don't think you've made a compelling enough
case for folks to become interested and wanting to work in this space
and help you solve your problem. You've also have been fairly
dismissive of the alternative points of view, such as the web being
fundamentally linked to HTTP and that distributing (offline)
applications over HTTP is the goal. That might make folks less
compelled to engage with you.

I suspect no browser, and I'm pretty certain about Mozilla since I
work there, is interested in furthering file URLs. Most new operating
systems abstract away the file system and the web as browsers see it
has always done that. There's ways to pull files in, but there's not
much use for letting applications write them out again (other than
downloads, which are quite a bit different).


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Tue, Apr 18, 2017 at 10:25 AM, Roger Hågensen <rh_wha...@skuldwyrm.no> wrote:
> On 2017-04-18 10:08, Anne van Kesteren wrote:
>> Right, those are about making applications distributed over HTTPS work
>> when the user is not connected. That idea doesn't necessitate file
>> URLs and we're still working towards that ideal with Fetch, HTML, and
>> Service Workers. All browsers seem on board with that general idea
>> too, which is great.
>
> But being able to access files added to a "subfolder" of said offline app
> won't be possible I assume?

I'm not sure what that means. But you can still interact with the app
and do things with it, including storing data if the app allows such a
thing.


> Maybe just adding the ability to ask the user if accessing this or that file
> or this and that folder for indexing (and accessing the files within) would
> be better.

There's  and https://wicg.github.io/entries-api/.


> Does the WHATWG and W3C meet/have a common group at all? (for the editors)
> So that cross-group messes can be handled/avoided?

Well, we talk now and then and that has resulted in some improvements,
but it's also still ongoing and some within the W3C actively try to
make it worse (e.g., DOM is being forked again without a good reason).
So, nothing good thus far.


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Tue, Apr 18, 2017 at 9:57 AM, Roger Hågensen  wrote:
> Searching Google for "offline webapp discussion group" turns up
> https://www.w3.org/wiki/Offline_web_applications_workshop
> and that's sadly from 2011.
>
> There is https://www.w3.org/TR/offline-webapps/

Right, those are about making applications distributed over HTTPS work
when the user is not connected. That idea doesn't necessitate file
URLs and we're still working towards that ideal with Fetch, HTML, and
Service Workers. All browsers seem on board with that general idea
too, which is great.


> Now I know that WHATWG and W3 Working Group is not the same thing,
> but if W3C thinks that offline apps are part of the web but WHATWG does not
> then that creates a huge chasm as WHATWG would then ignore all offline
> stuff.

The WHATWG collaborates with a W3C group on service workers. WHATWG
ends up being responsible for the underpinnings defined in Fetch and
HTML.


> I always assumed that WHATWG was a fast track variant of W3C. Brainstorming
> stuff, getting it tested/used in browsers then seeing what sticks to the
> wall and once things become stable the W3C will hammer it in stone. Is that
> assumption wrong?

A bit, they're more independent than that. (And we don't really
appreciate any copying that takes place. It's a lot less as of late,
but it still happens, as documented in e.g.,
https://annevankesteren.nl/2016/01/film-at-11 and
https://wiki.whatwg.org/wiki/Fork_tracking.)


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Mon, Apr 17, 2017 at 5:53 PM, duanyao  wrote:
> When we want to write a web application portable across multiple server
> OSes, these issues could happen too.

Yes, but then you run into implementation bugs. Which are a very
different category from proprietary OS design decisions.


> I think "portable" is never absolute.

Sure, but at least that's the goal for those participating in the
non-proprietary web ecosystem.


> There are always incompatibilities
> between browsers, and even once standardized feature can be
> deprecated/removed in future, e.g. `window.showModalDialog()`,
> `` and ``.

This happens rarely and when it happens it's a very considered
decision involving lots of people. It's usually related to complexity,
lack of use, and security.


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Mon, Apr 17, 2017 at 3:32 PM, duanyao  wrote:
> So you mean file: protocol is not portable? For absolute file: url, true;
> for relative url, almost not true.
>
> When writing web pages, no one use absolute file: urls in practice, so this
> is a non-issue.

Neither is portable or part of the web, since you don't allocate
resources on someone else their machine that way. (And even in the
sense that you mean it, they're not portable due to the different
styles of matching, case-insensitive, Unicode normalization, custom
variants of Unicode normalization, bytes vs code points, etc.)


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Mon, Apr 17, 2017 at 2:54 PM, duanyao  wrote:
> 在 2017年04月15日 02:09, Domenic Denicola 写道:
>> file: URLs are part of the web, e.g. parsing such URLs when used in 
>> tags, just like gopher: URLs or mailto: URLs. The behavior once navigating
>> to file: URLs (or gopher: URLs, or mailto: URLs) is off the web, and outside
>> the scope of the WHATWG's work.
>
> This still doesn't explain why file: protocol CAN'T be part of the web (and
> inside the the scope of WHATWG).

Because it's a mechanism for addressing resources on a specific OS.
It's not a mechanism for addressing resources on the web.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Anne van Kesteren]

On Fri, Apr 14, 2017 at 10:23 PM, Andy Valencia
 wrote:
> But the overarching issue is that you're doing JS-initiated
> network operations, and origin policy is going to stop you.
> You can claim Shoutcast/Icecast should give permissive
> origins, but they don't, and since an admin-ish interface is
> also multiplexed at the host, probably shouldn't.

If the same-origin policy stops you, it should also stop a C++
implementation. It's there for a reason.


-- 
https://annevankesteren.nl/

Re: [whatwg] Adding progress event for native ?

[Anne van Kesteren]

On Wed, Apr 12, 2017 at 9:16 AM, Mikko Rantalainen
 wrote:
> The default use case would not need to use frames. The expected use case
> would be to display custom UI for submission progress (e.g. nice
> progress bar and ETA with custom algorithm). It would be just fine to
> "lose" this custom UI once the submission is complete and next page or
> resource has been displayed.

Every now and then there's some talk about navigation transition
animations. That might be all you need here. (Sorry, no pointer at
hand.)


> About the information leak: in case of cross-origin the user agent could
> emit just one progress event with lengthComputable=false. However, I
> have throuble figuring out a possible attack vendor even in case full
> progress events were published cross-origin.

The problem is learning information about the destination server and
being able to do better timing attacks.


> I didn't understand the point about redirects making
> same-origin/cross-origin harder to distinguish.

Because at the point you'd hit such a redirect we'd have to stop
notifying you, but that would also reveal something if things are
still ongoing.


-- 
https://annevankesteren.nl/

Re: [whatwg] Adding progress event for native ?

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 2:44 PM, Mikko Rantalainen
 wrote:
> I see that https://xhr.spec.whatwg.org/ already defines ProgressEvent
> for XMLHttpRequest.
>
> Would it be possible to add "progress", "load", etc. events to normal
> form elements, too? Basically, I would like to do
>
>   form.addEventListener('progress', function (e) {...})
>
> and if the end user hits the Submit button, my progress listener would
> get called with ProgressEvent with lengthComputable, loaded and total
> attributes.
>
> If I have understood correctly, this does not make any information
> available to JavaScript that is not already available because JavaScript
> *can* already evaluate all form fields, use FileReader API to get all
> the files in file inputs and submit the form to the same action URL
> using XMLHttpRequest. In addition, browsers already implement all the
> required code because XMLHttpRequest needs that behavior.
>
> If listening for "progress" were allowed, I could implement my own form
> submission UI and still use regular forms that would work even without
> JavaScript.

It would leak new information cross-origin and due to redirects that
would be hard to distinguish from same-origin. You'd also have to
submit into some kind of  as otherwise you end up navigating
anyway.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Anne van Kesteren]

On Mon, Apr 10, 2017 at 6:44 AM, Philip Jägenstedt  wrote:
> There is a very old bug for exposing the metadata:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755
>
> In order to make progress, there needs to be implementer interest. Although
> it may well fizzle out, a new issue
> https://github.com/whatwg/html/issues/new with the concrete suggested
> changes for HTML would be a good starting point.

Demonstrating there's interest in this through a popular JavaScript
library or two would help a lot.


-- 
https://annevankesteren.nl/

Re: [whatwg] Subresource Integrity-based caching

[Anne van Kesteren]

On Fri, Mar 3, 2017 at 11:01 PM, Alex Jordan <a...@strugee.net> wrote:
> On Fri, Mar 03, 2017 at 09:21:20AM +0100, Anne van Kesteren wrote:
>> I think https://github.com/w3c/webappsec-subresource-integrity/issues/22
>> is the canonical issue, but no concrete ideas thus far.
>
> Great, thanks! I've got some thoughts on potential solutions; where
> would be the best place to put those - here or on GitHub? I'm assuming
> the latter but figured I'd ask :)

You are assuming correctly.


-- 
https://annevankesteren.nl/

Re: [whatwg] Subresource Integrity-based caching

[Anne van Kesteren]

On Thu, Mar 2, 2017 at 6:07 PM, Domenic Denicola  wrote:
> I don't know what the latest is on attempting to get around this, although 
> that document suggests some ideas.

I think https://github.com/w3c/webappsec-subresource-integrity/issues/22
is the canonical issue, but no concrete ideas thus far.


-- 
https://annevankesteren.nl/

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Anne van Kesteren]

On Wed, May 25, 2016 at 4:50 AM, Geoffrey Garen  wrote:
> My claim is that if you want English language with Russian regional settings 
> then browsers must report “en-ru” in navigator.language.

That doesn't work. What if you want British English and the Russian
locale? Or Canadian French with the US locale? A language tag already
uses that syntax to mean something else. You can't just repurpose it
to indicate locale.


-- 
https://annevankesteren.nl/

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Anne van Kesteren]

On Tue, May 24, 2016 at 1:55 AM, Nils Dagsson Moskopp
 wrote:
> • navigator.language is the language of the interface
> • HTTP Accept-Language is the language of content
> • ECMA-402 DefaultLocale() is the user's locale

The HTML Standard has a should-level requirement for the first two to
align, to avoid fingerprinting vectors. Also, Accept-Language is the
desired language, it's a request header, which navigator.language is
just the API for (and navigator.languages is the more complete API
for). Perhaps you're thinking of Content-Language.


-- 
https://annevankesteren.nl/

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Anne van Kesteren]

On Mon, May 23, 2016 at 11:58 PM, Geoffrey Garen  wrote:
> For example, if I speak English but I like Polish number formatting, should 
> navigator.language report “en-pl”?

I don't think so. That would only make sense if English was a language
spoken in Poland that differs from other English languages. Contrast
with en-GB and en-US which would make sense as values and don't imply
a locale necessarily.


> In researching this question, I discovered that lots of code uses 
> navigator.language and/or HTTP Accept-Language to infer the user’s locale, 
> despite the fact that language and locale are not equivalent.

I don't think we expose locale currently, although I have not studied
ECMA-402 in detail which I suspect might reveal some of it, only the
language.


-- 
https://annevankesteren.nl/

Re: [whatwg] Expose the 'renderport' to content

[Anne van Kesteren]

On Tue, Apr 5, 2016 at 10:26 PM, Matt Woodrow  wrote:
> Our suggested solution to this is to add a callback to scrollable elements
> that fires before painting (similar to requestAnimationFrame) and exposes
> the (approximate) region of the element that the UA is going to treat as
> visible for the purpose of painting.

This sounds very much like something CSS needs to define, together
with the scroll event. https://drafts.csswg.org/cssom-view/ might be a
better place I think. The HTML Standard defines when there is an
opportunity for scroll events to be dispatched relative to other
rendering matters, but not much more.


> It might also be nice to extend the IntersectionObserver spec to allow
> specifying the renderport (plus a margin) as the intersection region to
> observe, so that content can trigger asynchronous loading of data before it
> enters the renderport.

That suggestion probably best goes here:
https://github.com/WICG/IntersectionObserver.

Hope that helps.


-- 
https://annevankesteren.nl/

Re: [whatwg] Support filters in Canvas

[Anne van Kesteren]

On Fri, Feb 26, 2016 at 4:34 PM, Ali Juma  wrote:
> The current canvas filters proposal [1] allows using SVG reference filters
> defined in external documents (e.g. “url(file.svg#filter)”). Since the
> external document needs to be loaded before the filter can be applied,
> there’s a delay between setting the context’s filter attribute to such a
> filter and actually having the filter apply to drawing operations.

Perhaps we could support assigning an SVG filter directly (as an
object)? Developers would be responsible to load them if they're
external. Adding yet another network API that's a thin layer on top of
some CSS syntax seems a little hackish. I'd prefer if we exposed
filters at a lower level somehow.


-- 
https://annevankesteren.nl/

[whatwg] Standards development happening on GitHub

[Anne van Kesteren]

I wanted to remind the mailing list that currently all WHATWG
standards are being developed on GitHub. This enables everyone to
directly change standards through pull requests and start topic-based
discussion through issues.

GitHub is especially useful now that the WHATWG covers many more
topics than “just” HTML, and using it has already enabled many folks
to contribute who likely would not have otherwise. To facilitate
participation by everyone, some of us have started identifying
relative-easy-to-do issues across our GitHub repositories with the
label “good first bug”. And we will also continue to help out with any
questions on #whatwg IRC.

You should be able to find the relevant GitHub repository easily from
the top of each standard the WHATWG publishes. Once you have a GitHub
account, you can follow the development of a single standard using the
“Watch” feature.

* List of standards: https://spec.whatwg.org/
* GitHub: https://github.com/whatwg
* IRC: #whatwg, Freenode; https://wiki.whatwg.org/wiki/IRC
* Good first bugs:
https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+bug%22+user%3Awhatwg
* Good first bugs on Bugzilla (new issues go to GitHub, but some old
ones are still on Bugzilla):
https://www.w3.org/Bugs/Public/buglist.cgi?resolution=---_whiteboard=[good+first+bug]=WHATWG

There are no plans to decommission the mailing list — but as you might
have noticed, new technical discussion here has become increasingly
rare. The mailing list is still a good place to discuss new standards,
overarching design decisions, and more generally as a place to
announce (new) things.

When there’s a concrete proposal or issue at hand, GitHub is often a
better forum. IRC also continues to be used for a lot of day-to-day
communications, support, and quick questions.


-- 
https://annevankesteren.nl/

Re: [whatwg] Using time-origin-relative times for the .timeStamp property of animation events is not web-compatible

[Anne van Kesteren]

On Thu, Dec 10, 2015 at 10:00 AM, Boris Zbarsky  wrote:
> It looks like at least the angular-animate assumes that the .timeStamp
> property of animation events produces values that can be compared to
> Date.now() return values.  See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c3 for details.

Added a note to the corresponding issue:

  https://github.com/whatwg/dom/issues/23#issuecomment-163740275


-- 
https://annevankesteren.nl/

Re: [whatwg] Signature Link Relation for Cryptographic Resource Verification

[Anne van Kesteren]

On Wed, Dec 9, 2015 at 10:05 AM, Sean B. Palmer  wrote:
> I expect that I will be continuing this discussion largely with the
> WebAppSpec team, as their work is so obviously related to the contents
> of the Internet-Draft.

Thank you, that does indeed seem like the right place. And then from
there it can be merged into the HTML Standard down the road.


-- 
https://annevankesteren.nl/

[whatwg] OffscreenCanvas

[Anne van Kesteren]

Thanks to Olli I discovered
https://wiki.whatwg.org/wiki/OffscreenCanvas is much further along
than I thought. Is anyone planning on creating a PR against
https://github.com/whatwg/html for the more formal specification of
this feature? (And simultaneously ripping out the old worker canvas
text.)


-- 
https://annevankesteren.nl/

Re: [whatwg] : Issue reported by the web developers

[Anne van Kesteren]

On Wed, Nov 26, 2014 at 9:50 AM, Simon Pieters  wrote:
> Make the end tag optional and have ,  and  generate
> implied  end tags. (Maybe other tags like  and  can also
> imply .) The label attribute be honored if specified, otherwise
> use the textContent with leading and trailing whitespace trimmed.
>
> This would allow either syntax unless I'm missing something.

File an issue on doing this?

Are Firefox and Chrome (behind a flag) implementing this feature
identical otherwise? Anything they don't implement from the 
setup? It seems at this point we should cut our losses and remove
unimplemented markup features and defer to custom elements for the
foreseeable future.


-- 
https://annevankesteren.nl/

[whatwg] Removing mediagroup/MediaController from HTML

[Anne van Kesteren]

In https://github.com/whatwg/html/issues/192 we're planning on
removing mediagroup/MediaController from HTML since other than WebKit
no implementations appear interested in implementing these features.


-- 
https://annevankesteren.nl/

Re: [whatwg] Handling out of memory issues with getImageData/createImageData

[Anne van Kesteren]

On Sun, Sep 27, 2015 at 6:14 PM, Allen Wirfs-Brock
 wrote:
> Actually, that's not completely correct.  Within ES2015, the only way
> explicitly allocate a large, dense area of memory is by creating a large
> ArrayBuffer instance.  All attempts to create such instances eventually
> perform the actions specified by CreateDataBlock [1].  CreateDataBlock
> explicitly says that a RangeError exception is thrown if it is impossible to
> allocated the requested memory.
>
> I would expect and future ES features that exposed similar allocation
> capabilities to follow that same pattern.
>
> [1]: http://ecma-international.org/ecma-262/6.0/#sec-createbytedatablock

Thank you Allen. It would then make the most sense to rethrow that
exception for these  methods (and ImageData constructor). I
filed https://github.com/whatwg/html/issues/197 to track this. If
anyone is interested in working on this let me know. It should be a
relatively straightforward refactoring of the existing descriptions of
these features.


-- 
https://annevankesteren.nl/

Re: [whatwg] Handling out of memory issues with getImageData/createImageData

[Anne van Kesteren]

On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad  wrote:
> Currently there is no spec'ed behavior for handling out-of memory issues
> for the specific case of attempting to allocate a large buffer through
> image data APIs.

Actually, there is no specified behavior for out-of-memory behavior,
period. This is a problem that starts with the ECMAScript standard and
everything that builds upon it.

I have seen Mark Miller discuss some of the issues surrounding this
and perhaps even the necessity to eventually define it, but so far
this has not happened. Not sure if the full story is documented
somewhere. Mark?

https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
indicates there may be security issues with throwing out-of-memory
exceptions.


-- 
https://annevankesteren.nl/

Re: [whatwg] Icon mask and theme color

[Anne van Kesteren]

On Mon, Sep 14, 2015 at 12:11 AM, Karl Dubost  wrote:
> Nicolas Hoizey spotted on Apple forums and added a comment on the bug
>
>> The markup changed in Developer Seed 3 and Public Beta 1
>> to simplify and have better backwards compatibility.
>> Use the following markup instead:
>> 

This is now https://github.com/whatwg/html/issues/110.


-- 
https://annevankesteren.nl/

[whatwg] New ruby elements in HTML

[Anne van Kesteren]

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. (And slightly changed parsing rules
for  and  elements.)

Chrome uses HTMLUnknownElement for these elements, Firefox and Safari
use HTMLElement.

Firefox has also changed styling for these elements.

It's unclear to me what Edge has done.

>From this it seems pretty clear we should change the parsing rules,
for which the first commit of https://github.com/whatwg/html/pull/101
provides my recommended solution. It's less clear to me we should be
changing anything else.


-- 
https://annevankesteren.nl/

Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack

[Anne van Kesteren]

On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai c...@mozilla.com wrote:
 http://chiahungtai.github.io/mediacapture-worker/

Given that removeVideoProcessor() does not take arguments, should
addVideoProcessor() not check for duplicates?

VideoProcessEventThe looks like a typo.

The events don't define constructors. They probably should. You should
also use IDL [Exposed=] syntax to indicate they are available in
workers. (Or dedicated workers, anyway.)

The outputImageBitmap=null syntax is wrong. You want to remove =null
there and define the default in prose.

You also want to define the processing model a bit more carefully I
think. E.g., it seems to be that for processing the event instance is
modified and then once the dispatch flag is unset that data is copied
somehow. But how is it copied? Is it a structured clone transfer that
detaches the buffer?


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote:
 It is only used as way to group properties (perhaps similar to
 ValidityState?) and to keep History interface clean and stack-like. If that
 is not valuable enough to introduce a new interface then putting these on
 the History interface is fine.

I personally prefer flatter structures, but you're correct that
there's precedent for both and given a 1:1 relationship without setter
it does seem rather harmless.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn espr...@chromium.org wrote:
 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.

That would make event listeners observable.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn espr...@chromium.org wrote:
 Without such a function there's no primitive to explain how the scrolling
 and touch systems utilize this mayCancel bit unless we're saying the browser
 stores hidden state for event listeners in some WeakMap and all the browser
 systems use HiddenEventState.get(node).hasOnlyPassiveEventListeners(type).
 That's effectively what we'll have to implement internally, and if we don't
 expose it then we haven't explained the platform or given authors the
 ability to use this same optimization for their custom elements and events.

If you actually want to expose the primitives browsers use around
events you should advocate exposing the listeners. Since there's a
whole bunch of optimizations browsers already make based on the
presence/absence/type of those. But again, it's not entirely clear
that's a good idea.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

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.

(And the setTimeout() example is perfectly deterministic. It changes
the canceled flag, but after that flag has been consulted by the
dispatcher.)


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
 I think we've already made that assumption given that history.state
 already relies on this.

Good point. I'm still somewhat skeptical of introducing new objects
just for the purpose of grouping some properties if they don't serve a
purpose on their own.


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote:
 Minor bikeshed:
 I have put scrollRestoration on history.options instead of directly history
 itself in order to use history.options as an interface to contain any other
 restoration related attributes which have similar semantics (e.g., recorder
 scroll position, scale restoration, recorded scale).

Is the History object Document-bound in all implementations? Otherwise
adding new dependent objects will be problematic security-wise. Also,
History isn't that full and can easily contain a bunch of properties.
What's the use of a new object, can you use it independently somehow?


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola d...@domenic.me wrote:
 I'm not sure that actually matters though, since canceling inside 
 setTimeout(,0) shouldn't have much affect besides changing 
 `e.defaultPrevented`. So maybe it's OK.

It's fine. The code that dispatches an event and then checks the
event's canceled flag will run before a task queued by invoking
setTimeout() during dispatching runs. You can only change course if
you change the canceled flag during dispatch (which this new way of
listening would prevent).


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote:
 1) Should we extend the existing addEventListener API or change the API
 names (and perhaps other things) completely.
 https://github.com/RByers/EventListenerOptions/issues/18

It seems most other DOM peers are okay with overloading the third
argument. I can settle on that if that moves things along faster.


 2) Should mayCancel=false listeners always get an Event with
 cancelable=false, or is this just a hint such that all listeners still get
 the same event with the same properties.
 https://github.com/RByers/EventListenerOptions/issues/2

I was thinking that this basically sets a flag used during the
invocation of the listener that makes preventDefault() a no-op (or
throw?) for that listener. But it would not affect other listeners or
the Event object. The user agent could then make an optimization if no
traditional listener was added.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
 I think there's a big opportunity to substantially improve scroll
 performance on the web in the relatively short term by doing something
 incremental.  I.e. I'm pretty sure I can get major scroll-blocking libraries
 like Google Analytics to opt into the pattern proposed here in a relatively
 short timeframe.  I'm much less sure I could get them to switch to a
 completely new event API in any sort of reasonable timeframe.

Either way they need to branch their code, no?


 What do you think about an incremental path?  I don't see any fundamental
 reason that things need to change drastically.

Overloading a boolean argument with a dictionary seems bad. And if we
are to have a new API anyway, we might as well pick the better names.


 If we can get consensus on the basic approach, then I'd be happy to rework
 my proposal in the form of a pull-request and move all issue tracking to
 whatwg/dom.  There's probably no point in doing that until we have an
 agreement on the basic API shape, right?

Fair.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote:
 I'd love to hear other ideas!

Well, we have had some discussions in the past about introducing a
better event API:

  https://gist.github.com/annevk/5238964

Maybe the time has come...

(I agree with Philip that if we add this it would need to become part
of whatwg/dom. That seems like a better place for any GitHub
discussion too.)


-- 
https://annevankesteren.nl/

Re: [whatwg] IPv4 parsing

[Anne van Kesteren]

On Wed, Jun 24, 2015 at 10:56 PM, Ryan Sleevi sle...@google.com wrote:
[...]  All
the forms except for decimal octets are seen as non-standard (despite
being quite widely interoperable) and undesirable.

They are no longer non-standard, though still non-conforming. Or, in
other words, https://url.spec.whatwg.org/ has an IPv4 parser now.


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour maji...@chromium.org wrote:
 Do you have a preference one way or another for either of the above APIs?

Not really. The fact that history and navigation is not really
cross-browser makes me a bit wary about extending it further, since we
obviously don't really understand the primitives well, but I don't
have the bandwidth to tackle that at the moment.


-- 
https://annevankesteren.nl/

Re: [whatwg] IPv4 parsing

[Anne van Kesteren]

On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote:
 Also fun and probably worth documenting is how http://127.1/ and
 http://127.2.1/ are parsed. I doubt the average developer knows (unless they
 specifically deal with low level networking).

The question is whether the parsing happens at the URL parser layer or
at the network layer.


 You have http://0.0.0.66/ that's not a match for your example...

I'm not sure what you mean here.


-- 
https://annevankesteren.nl/

Re: [whatwg] IPv4 parsing

[Anne van Kesteren]

On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 You swap between 0.0.0.66 and 66.0.0.0 in your OP.

Actually, the input URL in that case is different. 0x42.0. != 0x42.


-- 
https://annevankesteren.nl/

[whatwg] IPv4 parsing

[Anne van Kesteren]

I've done some research into how Chrome parses IPv4 addresses to see
if that's worth standardizing.

Most browsers do not have special parsing rules for IPv4 vs domain
names. That is, they pass the domain name to the network layer and
let that figure out what should happen. Typically, that results in a
URL such as http://0x42。0./ (note the 。 and trailing .) to end up
connecting to IPv4 address 66.0.0.0 with 0x42.0. in the Host header.
The resulted parsed URL will be http://0x42.0./.

Chrome will instead have 66.0.0.0 in the Host header and its parsed
URL will have that value too. That means you lose functionality
Host-header wise, but it is more predictable (and no longer depends on
the networking stack) where you connect to. That seems somewhat more
secure, since it might not be entirely obvious that e.g. http://0x42./
is not a domain name. If the resulting URL is http://0.0.0.66/ it's
very clear what is going on. And we don't depend on whatever the OS
networking library does.

Now, is that what we want? Is losing the trailing dot acceptable?


-- 
https://annevankesteren.nl/

Re: [whatwg] Icon mask and theme color

[Anne van Kesteren]

On Thu, Jun 18, 2015 at 7:19 PM, Edward O'Connor eocon...@apple.com wrote:
 On the other hand, link rel=mask-icon color=darkslategray seems like
 it should Just Work™.

I guess we could add support for named colors to input type=color too.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Wed, Jun 17, 2015 at 9:42 PM, Benjamin Francis bfran...@mozilla.com wrote:
 It makes sense to me, an image element can have a src attribute of
 image.jpg and have a mask set to mask.svg in the mask CSS property.
 The equivalents here are the href attribute and the mask attribute, It's
 just that in your case you want to specify a solid colour to mask instead
 of an image, so you would omit the href attribute.

 That said, I'm not opposed to the creation of a new link relation with
 option A.2 if that's what people would prefer.

Not giving link another way to fetch resources seems preferable.
Might get tricky with error/load events and future fetching APIs
otherwise.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Wed, Jun 17, 2015 at 9:23 PM, Maciej Stachowiak m...@apple.com wrote:
 (A.2) Add an attribute to link specifically for use in specifying the color 
 for that icon, e.g. link rel=mask-icon href=whatever.svg color=lightred.
 (B.1) If the the color isn’t specified using the A method, use the theme 
 color.

 My current preference out of these is (A.2)/(B.1).

This seems reasonable to me too. Though perhaps color= should share
parsing with input type=color? More restrictive, but does not allow
transparency either, which CSS/canvas-like parsing would allow for.


-- 
https://annevankesteren.nl/

[whatwg] Relative URL plan

[Anne van Kesteren]

I've been trying to figure out a better data model for URLs so we can
handle relative URLs for any scheme. The motivation for supporting
relative URLs for any scheme can be found here:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233

Per my testing the URL parser would still need special handling for
what the URL Standard currently calls relative schemes. I will rename
those special schemes since any URL would now in principle be able to
handle relative URLs.

Testing of Chrome and Safari shows that even data and javascript URLs
have no special handling here. E.g.

  input | base URL | output
  test  | javascript:/ | javascript:/test
  data:/../ | (none)   | data:/

If fore the first example you then set host to test:81 you get
javascript://test:81/test in Safari. (Though if you set host to
/test:81 you get javascript:///test:81/test which seems bad. I
will treat that as a bug.)

This gives us three types of URLs:

* Special URLs. file/http/https/etc. These need to handle three
slashes after the scheme as two, can treat lack of slashes as
relative, etc.
* Relative URLs. All non-special URLs where the scheme is followed by a slash.
* Non-relative URLs. All non-special-non-relative URLs.

Non-relative URLs consist of {scheme, scheme data, query, fragment}.
Relative URLs and special URLs consist of {scheme, username, password,
host, port, path, query, fragment}. Special URLs cannot have an empty
host (as that would lead to reparsing issues), relative URLs can.
Relative URLs can also have a missing host (see javascript:/ above).

I think we should try to restrict backslash replacement and the
encoding override to special URLs.

I also think we should change the API such that you cannot change
anything for non-relative URLs (setters are no-ops, already largely
the case). And that you cannot change the scheme from a special URL to
a relative URL. Given the different handling of hosts that might lead
to security issues.

I will start rolling this out and write a bunch of tests. Even though
both Chrome and Safari implement this they have differences and some
logical inconsistencies that I think would be great to remove. I hope
to get feedback on what we cannot do from the above. Hopefully Firefox
not implementing any of this provides some wiggle room.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 about: is not standardized enough across UAs to really reason about.

about and mailto are the reasons query is split out. Not so much that
you can set it (you can't), but so that you can reason about it
independently. And since non-Gecko-browsers don't have a parser
per-scheme and that didn't really seem like a viable path forward
anyway, data follows that logic.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 6:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/16/15 8:06 AM, Anne van Kesteren wrote:

 I also think we should change the API such that you cannot change
 anything for non-relative URLs

 Why would you disallow setting fragment for a non-relative URL?

You're right, fragments make sense. Changing path (scheme data in the
specification) or query would be painful however.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 What are examples of non-relative URIs that use query?  mailto:, I guess?

about, data, etc. Though note that there's no such thing as
non-relative URL. That completely depends on the first code point
after the scheme and : in this brave new world.

As far as I can tell apart from special casing a couple of schemes
(now named special schemes in the URL Standard), everything else can
be completely generic at the parser level. Of course there's also a
level on top, e.g. for data URLs we'd look at scheme data + (query ?
? + query : ).

The non-special URLs have a couple of forms:

  non-special:non-relative-path
  non-special:/null-host-and-relative-path
  non-special://host/and-relative-path
  non-special:///empty-host-and-relative-path (supporting this for
special URLs is impossible due to reparsing issues)

and apart from non-relative-path can be manipulated quite easily.
Non-special URLs also don't have their host names IDNA-parsed.

I'm actually pretty happy this seems within reach as it makes URLs
much more extensible. I suppose we might still sometimes wish to make
tweaks to the parser (as we did for e.g. blob URLs), but overall this
should be much more compatible with the IETF POV.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 Why can't you?  If it's something you want to reason about as a separate
 entity, why doesn't it make sense to set it as a separate entity?

Actually, it seems like you can, though that would equally affect data
URLs, but maybe that's not too bad. I guess for the API we could
special case a couple of schemes to not support reading/writing as
desired for optimizations.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 8:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 What optimizations are we talking about here, specifically?

Not sure. Was just indicating that we have that option if it would be
particularly painful/pointless/footgun. I haven't exactly thought it
through and there's not much feedback beyond http/https use cases.


 Note that my general view for how URL objects should work internally in
 Gecko is that we should have an immutable backing store and mutators that
 clone-with-modifications (basically copy on write).  Of course in terms of
 the web-exposed behavior we'd just have the web-exposed URL change which
 internal object it points to on mutation, so we can expose whatever mutators
 we want.

Makes sense. In retrospect I kind of wished new URL() at least started
out immutable, so it could become a native value in JavaScript some
day, but too late now.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Before we start bikeshedding, can you commit to actually changing your
 implementation?  Safari has already shipped with the exact proposal
 given in this thread; if you're seeking a rubberstamp rather than a
 collab, say so.

Maciej already clarified this, no? They're perfectly happy to change
this before Safari 9 ships, provided, I'm guessing, that we settle
this somewhat quickly.


-- 
https://annevankesteren.nl/

Re: [whatwg] Icon mask and theme color

[Anne van Kesteren]

On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński kor...@geekhood.net wrote:
 The new Safari is still only a preview, so I hope Apple will switch to a 
 better solution.

It would be great if we could get some feedback from Ted  colleagues
on what the thinking here was.


-- 
https://annevankesteren.nl/

Re: [whatwg] Icon mask and theme color

[Anne van Kesteren]

On Mon, Jun 15, 2015 at 7:33 PM, Edward O'Connor eocon...@apple.com wrote:
 Our proposal is simply to add mask= to this list of advisory
 attributes that are used to determine an icon's appropriateness here.
 User agents that don't understand mask= should continue to pick the
 most appropriate icon given the other attributes. If there is a tie, the
 last link rel=icon wins. That is why we recommend authors put link
 rel=icon mask first—so that the existing tie-breaking behavior results
 in the legacy favicon being chosen.

I think the only problem with this advice is that it lacks the bit
where you need to list link rel=icon href=/favicon.ico explicitly
(and last) once you add a link rel=icon mask entry. That seems to be
the reason why Twitter is now black rather than light blue in Firefox.


-- 
https://annevankesteren.nl/

Re: [whatwg] Regarding spec clarification on dispatching click event on disabled form controls

[Anne van Kesteren]

On Thu, May 7, 2015 at 12:21 PM, Ramya Vadlamudi ramy...@samsung.com wrote:
 https://html.spec.whatwg.org/multipage/forms.html#concept-fe-disabled

 A form control that is disabled must prevent any click events that are
 queued on the user interaction task source from being dispatched on the
 element.

 Which means except for click events generated by user interaction through
 mouse or keyboard, all other generated events should be dispatched to
 disabled elements.

Actually, it only says the former (since only those end up on the user
interaction task source). It makes no claims about what should happen
for other events.

 https://html.spec.whatwg.org/multipage/interaction.html#dom-click

 The click() method must run the following steps:

 If the element is a form control that is disabled, abort these steps.

 which means even if DOM click is a generated event it should not be
 dispatched to disabled elements, which looks to be bypassing first spec.

It does not bypass, it's just a different requirement.


 For ex: In javascript if button is a HTMLButtonElement

 button.click();   -  As per spec2 event should not be dispatched, as per
 spec1 event should be dispatched

No, spec1 does not apply here.


 button.dispatchEvent(new Event('click'));  - As per spec1 event should be
 dispatched.

Spec1 does not apply here and neither does spec2. So yes, this should
be dispatched, since there's no evidence to the contrary.


 Attached sample test file for you reference.

You might want to upload that somewhere. It did not get through at
least for me. Your browser results were also mangled in a text/plain
view of your email (which is the only one I got).


-- 
https://annevankesteren.nl/

Re: [whatwg] Regarding spec clarification on dispatching click event on disabled form controls

[Anne van Kesteren]

On Fri, May 8, 2015 at 12:07 PM, Ramya Vadlamudi ramy...@samsung.com wrote:
 Is there any specific reason to prevent click events that are queued on the
 user interaction task source only?

Presumably that's the legacy behavior.


 What should be the behavior of other events like button.dispatchEvent(new
 Event('click'))?

 From the results we can see IE and Firefox are not dispatching any click
 event generated to disabled elements.

 Please let me know the correct behavior.

I would say that both IE and Firefox are wrong. dispatchEvent() should
always work. There's nothing in the dispatchEvent() specification that
says it shouldn't for this case.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I don't think ascii case-insensitivity is a mistake here.

(ASCII) case-insensitivity is a mistake. JavaScript doesn't have it
and wherever we do have it it's sticking out as sore thumb with a
dozen subtleties attached.


-- 
https://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Well, beyond the existing conflicts of style, script, and a.
 (font too, but that's dropped from SVG2, so who cares.)

textArea is out too?

With respect to case-insensitive matching, I don't really understand
why we simultaneously want to make these rather trivial changes to SVG
while at the same time move to constructors for creating elements,
which is even stricter than createElementNS() (literal has to be
correctly spelled or you get an exception). If we want to move to a
world where people write

  new SVGRectElement

why would we even bother making

  document.createElement(RECT)

work?

Same for CSS, the majority of CSS already uses type selectors where
the case matches up with the HTML. Is complicating it really worth it?
We should bring the languages closer, but we shouldn't put the
mistakes we made with HTML into SVG.


-- 
https://annevankesteren.nl/

[whatwg] Outstanding URL bugs

[Anne van Kesteren]

I won't have much time to work on URLs until July most likely.
However, I was asked to provide an update of sorts with respect to
changes that are planned:

* Support relative URLs outside of the whitelist of relative schemes.
We'll still need special parsing rules for the relative schemes, and
we'll need to blacklist some other schemes, such as data and
javascript, but we can support relative URLs for random schemes and
make sure ../test can be resolved against test://test/x/.

* Support IPv4 including addresses such as http://2/ by normalizing them.

* Fix the outstanding issues with file URLs. Perhaps we need to
acknowledge the Unix / Windows mode switch although it seems somewhat
sad to depend on global state in that way.

* No longer default base URL to about:blank. Boris pointed out that
even with about:blank some relative URLs ought to work, such as
#test, which would mean you could no longer use new URL() to only
succeed for absolute URLs. (I might try to fix this one sooner.)

I've also been thinking of rewriting the parser from being state-based
to function-based, though a recent new URL implementation
https://github.com/jsdom/whatwg-url is state-based so maybe the
current setup is okay.


-- 
https://annevankesteren.nl/

Re: [whatwg] Storage Standard

[Anne van Kesteren]

On Fri, May 1, 2015 at 9:40 PM, Jonas Sicking jo...@sicking.cc wrote:
 Can't we use the permission API [1] for this? I.e. use the permission
 name persistent-storage or some such? So rather than default we're
 return prompt.

 [1] https://w3c.github.io/permissions/

I'm sorry, what do you mean by this? I filed an issue a while back
on that specification for trying to needlessly change terminology:

  https://github.com/w3c/permissions/issues/25

If you mean persistentPermission() by this, the reason that is there
is because we have done the same thing for other new APIs, such as the
Push API.


-- 
https://annevankesteren.nl/

Re: [whatwg] Storage Standard

[Anne van Kesteren]

On Mon, May 4, 2015 at 9:47 PM, Jonas Sicking jo...@sicking.cc wrote:
 By this I mean the API discussed in this thread :)

Well this thread is for the Storage Standard, which has several APIs.


 More specifically, I'm proposing to remove the persistentPermission()
 function in favor of using navigator.permissions.query({ name:
 persistent-storage });

Okay, I defer to e.g. these recent threads

  https://github.com/w3c/push-api/issues/136
  https://github.com/slightlyoff/BackgroundSync/issues/39

where we decided to keep similar APIs.


-- 
https://annevankesteren.nl/

[whatwg] Storage Standard

[Anne van Kesteren]

Based on the discussion on this list and on:

  https://wiki.whatwg.org/wiki/Storage
  https://github.com/slightlyoff/StorageDurability

Here's a first draft:

  https://storage.spec.whatwg.org/
  https://github.com/whatwg/storage
  https://twitter.com/storagestandard

It does not address multiple boxes for now. I hope we can continue
discussing those in parallel, perhaps in the GitHub repository, as
they are important to the gaming industry. Boxes can really help in
the case where the site is trying to do the right thing and wants to
avoid prompting the user, and also would allow introducing new global
strategies such as an actual API-exposed cache (service workers' Cache
API is all-or-nothing like any other API), or boxes with a max-age.


-- 
https://annevankesteren.nl/

[whatwg] EventSource and data URLs

[Anne van Kesteren]

Currently Chrome supports data URLs inside EventSource whereas in
Firefox EventSource is restricted to http/https URLs:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1156137

What's the convergence we want here?


-- 
https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

I removed some people from the cc. The WHATWG list seems to bite.

On Thu, Apr 16, 2015 at 6:57 PM, Ryan Sleevi sle...@google.com wrote:
 I think as we look to
 provide a compelling story for EME over wholly-proprietary (... rather than
 partially-proprietary) solutions, or look to improve the user experience in
 streaming video with MSE vs the video tag, this is still very much needed.

Okay, so accepting that for the moment, that leaves us with deciding
on the appropriate API on the MSE side. I don't have a strong
preference, but at this point MSE is the only case I can think of that
warrants an explicit opaque readable stream class. All the other use
cases I have (such as feeding img or script an arbitrary response)
would rather have a Response instance so headers and such are
preserved. And that Response can be opaque of course and then (as
currently specified) its .body would return null, but these privileged
contexts would get access to the underlying body stream.

I don't particularly mind introducing an opaque readable stream class,
but do we have any other use cases besides MSE?


-- 
https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

On Wed, Apr 15, 2015 at 6:45 PM, Martin Thomson
martin.thom...@gmail.com wrote:
 I believe that the easiest way to avoid this is to make an attempt to
 read Response.body raise a SecurityError if the origin is different
 (in Firefox terms, we would say if the response principal is not
 subsumed by the script principal).

The proposal is that .body returns an opaque stream object that you
cannot read from, but privileged code can. But yes, same general idea
as the SOP dances elsewhere.

Having said all this, it has come to my attention that Netflix had a
change of heart so maybe we do not want to put effort into this new
Mixed Content API? It could still be useful for
same-scheme-cross-origin-no-cors of course, but nobody has asked for
that.


-- 
https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

On Mon, Apr 13, 2015 at 10:34 PM, Matthew Wolenetz wolen...@google.com wrote:
 Certainly. As I understand it, the reasons for reusing appendStream() rather
 than adding appendResponse() to MSE are generally two-fold:
 a) MSE already has appendStream(). In combination with the other changes to
 Streams API, Fetch, and Mixed Content specs, as well as the known work to
 update MSE spec to use ReadableByteStream
 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239), the scope of further
 changes to existing MSE appendStream() spec are expected to be significantly
 less than adding a distinct appendResponse() method to MSE.
 b) We think these other specs (Streams API, Fetch, Mixed Content) are likely
 to incorporate these changes anyway.

Well, except now you make yourself depend on some definition of an
opaque stream object which nobody has defined yet. Perhaps we should,
but that will take longer and won't be less work (though maybe less
work long term).


-- 
https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

On Tue, Apr 14, 2015 at 9:38 PM, Domenic Denicola d...@domenic.me wrote:
 I also imagine it won't be too hard to spec, as the point of an opaque stream 
 type is that most of its methods consist of magic happens here (roughly 
 speaking).

Well, we also need to ensure that nothing that takes a stream and then
exposes it either client or server-side (e.g. Request, Response,
fetch()) can handle them. (Which is a different primitive from what
Credential Management wants by the way, they just want to avoid
exposing the request body stream client-side, probably with the
exception of service workers.)

That is, the following should reject:

  fetch(url, {mode:no-cors}).then(res = fetch(url2, {body:res.body}))

None of that should be particularly hard, though I do worry that the
further we get away from Response, the more we might lose sight of
what we are trying to protect and make mistakes.

(Perhaps the Credential Management case does not need to use streams
at all. We could extend FormData to have an opaque mode or some such.)


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
 I'd strongly recommend against adding new methods. It'll mean we now have
 two different ways to do the same thing, which means more bugs, which
 means less interoperability, more confusing behaviour for authors, more to
 document, etc.

If the existing method didn't have the flaw with the title argument I
wouldn't have suggested it. Also, since they both built upon the same
primitive I think we'd be okay in the bugs and interop department.


 I think the original approach of adding a fourth argument is much better.

 It's also a better API in general, since the URL should always be given.
 If we had a one-argument form with a dictionary, people would consider not
 giving the URL but just disabling scrolling, which is suboptimal.

You can require arguments with dictionaries.


-- 
https://annevankesteren.nl/

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

On Sat, Apr 11, 2015 at 12:24 AM, Matthew Wolenetz wolen...@google.com wrote:
 After further internal discussion, we believe we can and should reuse
 appendStream() rather than adding appendResponse().

For those not privy, could you share the reasoning?


-- 
https://annevankesteren.nl/

Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen

[Anne van Kesteren]

On Tue, Mar 31, 2015 at 12:47 AM, Seth Fowler s...@mozilla.com wrote:
 I think we should modify the Page Visibility spec to let UA’s take actual 
 visibility of iframes into account when deciding if an iframe is hidden.

Wouldn't it be better to discuss that on public-web-perf?


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Wed, Mar 18, 2015 at 1:38 AM, Krinkle krinklem...@gmail.com wrote:
 I'd like to share a use case and problem we have at Wikipedia with
 localStorage.

Thanks, this is great feedback.


 I imagine HTTP2 might make it appropriate to phase out batches and just
 request modules individually (always) and let the network layer do the
 combining and separated caching in a more natural way.

Yeah, hopefully.


 * A way to know if a url is cached or not (e.g. know whether a url will hit
 HTTP 304) without making the request.

Maybe we can expose that same-origin, not sure. Depends a bit on the
implementer feedback we get for fetch()' cache feature. But
privacy-wise it's somewhat problematic to reveal what is in the cache
as the cache is not unique per-origin.


 * A way to prioritise which entries should be kept in localStorage and allow
 for low-prio entries to be evicted if short on space.
 * A way to know how much localStorage is available in total.
 * Perhaps a way to create a limited store within localStorage or IndexDB
 that has limited/restricted capacity (with some unique identifier, capacity
 percentage-based, or a min/max byte size?).
 * A separate store for caching HTTP resources (the Service Worker's Cache
 API?)

The current setup is basically a storage area per site with LRU
semantics. It's not completely done yet as not all storage features
share the same store, but they will eventually. Persistence is planned
as per OP.

We have two other ideas roughly along the lines of what you ask for:

1) Allow a site to mint new storage areas. If we keep doing LRU on
storage areas rather than sites that would allow for e.g. a game
engine staying preserved while the initial set of levels (one per
storage area) that are no longer played are cleared.

2) A storage area that acts like a cache. Resources that are not
frequently used get deleted before those that get frequently used get
deleted.


-- 
https://annevankesteren.nl/

Re: [whatwg] Array as first argument to fetch()

[Anne van Kesteren]

On Fri, Mar 27, 2015 at 1:28 PM, Brett Zamir bret...@yahoo.com wrote:
 Since fetch() is making life easier as is and in the spirit of promises, how
 about taking it a step further to simplify the frequent use case of needing
 to retrieve multiple resources and waiting for all to return?

 If the first argument to fetch() could be an array, then fetch() could be
 made to work like Promise.all() and return an array of the results to
 then().

It seems easy enough to just write that yourself, e.g.

  Promise.all([image, script].map(url = fetch(url)))

works fine in Firefox Nightly.


-- 
https://annevankesteren.nl/

Re: [whatwg] Array as first argument to fetch()

[Anne van Kesteren]

On Fri, Mar 27, 2015 at 1:50 PM, Brett Zamir bret...@yahoo.com wrote:
 Thanks, I realize it's doable that way, but I think it makes for less
 distracting code when the implementation details of the map call and such
 are avoided for something as basic as loading resources...

Write a function that abstracts it... If everyone opts to use that
instead of fetch(), we can revisit.


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour maji...@google.com wrote:
 My only concern is to make sure that these new methods replace
 history.pushState() and history.replaceState() in the spec. Otherwise I feel
 the benefits of a cleaner API is not worth the additional confusion of
 having different methods for doing (almost) the same thing.

Well, I doubt that they can, maybe over a very long period of time but
I wouldn't count on it. However, if MDN describes them as more capable
methods (and without the useless second argument), I doubt there will
be much confusion. Having four required arguments is no picnic either.


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour maji...@google.com wrote:
 That is fair. Assuming clear documentation helps alleviate potential
 confusion I am fine with deprecation route. I suppose the purpose of the
 spec is to not only document the current recommended behavior but also
 capture any legacy ones until it is fully removed.

Yeah, we don't want any new user agents such as Spartan or Servo run
into pages that only work with history.replaceState(). They'd then
have to reverse engineer it rather than simply reading a specification
which is not nice.


-- 
https://annevankesteren.nl/

Re: [whatwg] Seamless browsing context in object elements

[Anne van Kesteren]

On Tue, Mar 24, 2015 at 11:06 PM, Andrea Rendine
master.skywalker...@gmail.com wrote:
 Is there a reason why it does not apply to object browsing
 contexts?

Yes. object does too much (it can handle both browsing contexts and
embedding contexts) and therefore we shouldn't extend it more. Both
object and embed are problematic for offline solutions as well,
see application caches and now service workers...


-- 
https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Anne van Kesteren]

On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour maji...@chromium.org wrote:
 partial interface History {
   void pushState(in any data, in DOMString title, in optional DOMString
 url, in optional StateOptions options);
   void replaceState(in any data, in DOMString title, in optional DOMString
 url, in optional StateOptions options);
   readonly attribute StateOptions options;
 };

 dictionary StateOptions {
 Boolean restoreScroll = true,
 }

The only suggestion I have is that instead of having four-argument
methods we might want to consider introducing two new methods that
take a dictionary. E.g. history.push() and history.replace(). Giving
the page more control over the scroll position when navigating makes
sense to me.


-- 
https://annevankesteren.nl/

Re: [whatwg] Responsive image maps

[Anne van Kesteren]

On Wed, Mar 25, 2015 at 3:21 PM, Andrea Rendine
master.skywalker...@gmail.com wrote:
 Yes, I think I should have expressed it better. Why not improving *this*
 specific feature?

That's generally not how we do things. We don't start looking at an
existing set of features and figure out how we can add some flair.
Instead, we start by figuring out what problems need solving. You
might want to study the rest of the FAQ and in particular:

  
https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


-- 
https://annevankesteren.nl/

Re: [whatwg] Canvas image to blob/dataurl within Worker

[Anne van Kesteren]

On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
 My understanding is that the current consensus proposal for canvas in
 Workers is not what's in the spec, but this:
 https://wiki.whatwg.org/wiki/WorkerCanvas
 See Canvas in Workers threads from October 2013 for the discussion. svn
 is failing me but the CanvasProxy proposal in the spec definitely predates
 those threads.

 Ian, unless I'm wrong, it would be helpful to remove the CanvasProxy stuff
 from the spec to avoid confusion.

 That proposal contains WorkerCanvas.toBlob, which needs to be updated to
 use promises.

There's also https://wiki.whatwg.org/wiki/WorkerCanvas2 it seems. It
would be interesting to know what the latest on this is. Canvas in
workers has been discussed for a long time now and we're still not at
the point of implementing.


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Mon, Mar 16, 2015 at 5:23 PM, Joshua Bell jsb...@chromium.org wrote:
 On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
 But that for persistent it can be
 the whole disk.

 ... and we're waffling on that one. Going that far implies that the UA does
 a really good job on its own or with user interaction to respond when the
 storage is indeed getting full. Mobile OSes typically provide UI to inspect
 how much storage is in use and clear apps and/or portions of their storage.
 IMHO, we need to fully develop that UX in the UA before I'd be comfortable
 letting sites easily consume the whole disk.

Yeah, getting better UX/UI is a prerequisite for us as well. Firefox
has a page about:permissions today. Something like that, but more
easily accessible and without its issues would go some way towards
addressing this. And perhaps making sure the user discovers it when
they are about to run out of disk space...


 If I'm reading the wiki page correctly, I'm intrigued by the temporary
 proposal. To confirm, you're envisioning a completely new lightweight
 storage API and there's no implied addition to the other storage APIs? If
 so... well, pros and cons. I'm not a huge fan of adding Yet Another Storage
 API. On the other hand, I'd rather do that then fork the existing storage
 APIs into temp/persistent and try and shoehorn priorities into those.

I think that's really v2 material anyway. Another idea we had is
having named storage areas and then assigning priorities to those,
with initially the whole site being in a single area.


 If it helps I did a thought experiment a while ago on what would a
 stripped-down, Promise-based IDB-lite look like? at
 https://gist.github.com/inexorabletash/c8069c042b734519680c - it doesn't
 have the priority scheme, but that would be easy to add at the 'open' entry
 point.

Yeah, this is also something that warrants more discussion. There's
cookies, localStorage, indexed DB, various filesystem APIs,
notifications API, history API, and indeed always the question whether
we want a nicer indexed DB / asynchronous localStorage.

Also seems like v2 material. Something we should consider after
bridging the persistence gap.


 One thing we should discuss under the storage umbrella is how atomically we
 treat all storage for an origin. Customers we've talked to acknowledge the
 reality that even durable storage can be wiped in the face of user action
 (e.g. via settings UI to clear cookies etc) or file corruption. One of the
 situations they're concerned about is dealing with partial clearing of
 data, e.g. Indexed DB databases are present but the SW cache has been
 wiped, or vice versa. Currently, for quota-based storage eviction, we evict
 an origin's entire storage at once - that's easiest for sites to reason
 about, since it matches the first time user or returning user on new
 device scenarios that must already be supported. If we're taking a step
 back to think of storage as a whole, we may want to provide more spec-level
 assurance in this area.

Yeah, I think until we'd introduce something like named storage areas
or temporary storage APIs we should treat everything under the
best-effort / persistent banner as atomic. We should probably define
that in the specification that outlines this storage architecture and
then the various storage APIs we have can tie into it.


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Fri, Mar 13, 2015 at 3:25 PM, Janusz Majnert j.majn...@samsung.com wrote:
 On 13.03.2015 15:01, Anne van Kesteren wrote:
 The reason developers want it is to know how much they can download
 and store without getting an exception.

 Which still doesn't guarantee they won't get an exception if the device runs
 out of space for whatever reason.

That is true, it would be an estimate (and I think we should name it
as such in the API). With deduplication and compression it can't be
super accurate. It's still better to reason with an estimate than with
nothing at all though, I think.


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell jsb...@chromium.org wrote:
 A handful of us working on Chrome have been having similar discussions
 around what we've been calling durable storage. In its simplest model a
 bit granted by the user to an origin, which then requires explicit user
 action before the data might be cleared under storage pressure, so it
 sounds like our thinking is broadly aligned, although we're still exploring
 various possibilities and their implications for permission prompts,
 cleanup UI, behavior under pressure, etc.

Yeah, same here, wiki page outlines a tentative plan.


 Similarly, we've been trying to keep this orthogonal from quota (either the
 UA's logic for assigning a quota to an origin quota, or possible
 standardized quota APIs), although the UA may use similar signals for
 granting permissions/assigning quota.

I think we've come around in that we need to expose quota in some way
to give developers some expectations to how much they can fetch and
then store in best effort mode. But that for persistent it can be
the whole disk.


 (FYI, we've been using durable and non-durable to distance the
 discussion from the now-loaded temporary vs. persistent terms which
 surfaced in earlier API proposals, some of which are implemented in Chrome)

Ah right. Current set of terms I have is best effort (default; fixed
quota), persistent (requires some kind of user opt-in, probably
through an API-triggered dialog, but maybe also done if you pin a tab
or bookmark or some such; 'unlimited' quota), and temporary (exists
outside of best effort/persistent, e.g. for storing social network
resources, other volatile assets, requires some kind of API opt-in;
fixed quota).


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Mon, Mar 16, 2015 at 4:12 AM, Biju bijumaill...@gmail.com wrote:
 At present data stored in indexDB is written some where deep in the
 profile folder, which is difficult to find.

I don't think we should expect our users to traverse the directory
structure at all. We need to expose UI to manage sites in
about:preferences or equivalent.


 Additionally if we can restrict these kind of file/storage access to
 just https site (or some sort of signing mechanism for installed
 app),, it will help reduce annoyance of asking for permission by ever
 other site we visit.

I suspect this will be HTTPS restricted simply because it is about
persistence, but soon every site will have easy access to HTTPS. So if
indeed all sites end up asking for this we would need to think of a
better model, but I doubt that will be the case.


-- 
https://annevankesteren.nl/

[whatwg] Persistent and temporary storage

[Anne van Kesteren]

A big gap with native is dependable storage for applications. I
started sketching the problem space on this wiki page:

  https://wiki.whatwg.org/wiki/Storage

Feedback I got is that having some kind of allotted quota is useful
for applications. That way they know how much they can put away.
However, this clashes a bit with offering something that is
competitive with native.

We can't really ask the user to divide up their storage. And yet when
the user asks an application to store e.g. a whole bunch of music
offline we don't really want the user agent to get in the way if the
user already granted persistence.


-- 
https://annevankesteren.nl/

Re: [whatwg] Persistent and temporary storage

[Anne van Kesteren]

On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote:
 The real question is why having a quota is useful?

The reason developers want it is to know how much they can download
and store without getting an exception.


 Native apps are not
 controlled when it comes to storing data and nobody complains.

Is there any documentation on how they handle the above scenario? Just
write to disk until you hit failure?


 I think proper solution would be not to restrict the available space, but
 provide GUI for users to:
 * see how much space an app uses (if it exceeds some preset amount)
 * inspect the files in platform's file explorer

Agreed that we need much more solid UI for users to control sites. I
would expect the granularity to be more along the lines of delete
all initially, though.


-- 
https://annevankesteren.nl/

Re: [whatwg] Effect of image-orientation on naturalWidth/Height

[Anne van Kesteren]

On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote:
 I wanted to get the opinion of this list on how image-orientation and the 
 img element’s naturalWidth and naturalHeight properties should interact.

I thought there was some agreement that image-orientation ought to be
a markup feature as it affects the semantics of the image (or perhaps
investigate whether rotating automatically is feasible):

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508


-- 
https://annevankesteren.nl/

[whatwg] MessageEvent and ports

[Anne van Kesteren]

Can someone explain why the postMessage() design exposes transfered
ports both in .data and .ports?

If that's a legacy artifact, can we call that out somewhere?

(Asking around on IRC suggests it's an artifact that needs to be
preserved by new variations of the postMessage() design, as e.g. seen
in service workers. So the API remains somewhat consistent across
variations. We might want to stipulate that too somehow.)


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 7:52 PM, Fady Samuel fsam...@chromium.org wrote:
 This is obviously larger than the particular set of use cases mentioned
 here, but another set of iframe discussions I've seen lately have centered
 around going off thread or out of process. I wonder if there is a more
 basic primitive here that can apply to all these use cases [and perhaps
 even allow for new behaviors we haven't thought of]? Perhaps a new email
 thread would be appropriate for such a discussion?

One problem with having a switch that does more than asked for is that
it might not get you the adoption you want. Often when deployed web
sites are already complicated it's easier to add something that
changes a single thing than add something that changes a bunch, some
of which you might not need.

Would love to see more ideas though, either here or in a new thread.


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 7:31 PM, Ashley Gullen ash...@scirra.com wrote:
 Perhaps independent is a better name than async, indicating the iframe
 content is independent of the main page. Browser loading UI, load events,
 fast back and possibly performance tools would not take in to account
 independent iframes, since they are explicitly marked as not important to
 the working of the main page.

Yeah, async was poorly chosen as subject in hindsight.


 I think there are widespread use cases for this: ads and those social icons
 (facebook, tweet etc) are all iframed, and I've seen pages look like
 they're really slow because they're waiting for a Tweet button to load when
 the main page was ready long ago. Performance tools is another case I bring
 up because I've seen some tools say the page took say 2 seconds to load,
 when the main page was really ready after 300ms and then it spent 1.7
 seconds waiting for the Tweet button to finish its thing. It would be nice
 if performance tools could identify the independent iframe and not include
 it in such calculations.

Yes, exactly.


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 3:59 PM, David Bruant bruan...@gmail.com wrote:
 The request is to being able to
 provide different priority orders to different iframes (some containing not
 important content like ads, others containing important content) while what
 I'm suggesting treats all iframes the same way.

Yes, less important and therefore should not block the load event or
any UA notion of complete. Fast back is a feature that some
browsers implement where pressing the back button revives some object
structures rather than loading the page again from disk or network.


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote:
 The exact same question stands for implementors of the current proposal.
 Until what point should a browser delay loading the iframe?

 The difference being that the author knows the relative importance of the
 various iframes among themselves and with the parent (at least better than
 the browser) and can make the choice between (non-exhaustive list):
 * a delay in ms after the delaying script starts executing
 * after DOMContentLoaded or load
 * or any amount of time after one of the two events. Maybe choose to
 load after twice the time it took for DOMContentLoaded (which one can know
 via performance API)
 * after first paint (there is a way to know when that happens, right? or
 with an upcoming spec?)
 * after some other resource has loaded (maybe to chain iframe loading)
 I'm sure there can be other reasonable options.
 I don't think it's reasonable for browsers to implement all these options.

All of those delay the load event per earlier emails...


 You said that you got feedback from someone asking for this.
 What is the behavior they currently implement?

Today they stamp out the template and users suffer (somewhat).


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote:
 To achieve this priorization, currently, authors would use a bit of JS to
 delay adding the iframe to the document. It seems like it solves all the
 issues listed in the original message (load UI, load event, fast back).

Delay until what point? They could navigate I suppose, but it seems
rather clumsy.


 What is the significant benefit to adding an HTML attribute to solve this
 problem?

Not having to change infrastructure.


-- 
https://annevankesteren.nl/

Re: [whatwg] iframe async

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 4:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 onload, if you don't want it to block onload.

Yeah that seems like a pretty bad alternative. That would be quite a
significant delay.


-- 
https://annevankesteren.nl/