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

[Ryosuke Niwa]

> On Oct 25, 2019, at 10:34 AM, Chris Wilson  wrote:
> 
> On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak  wrote:
> 
>> So on the whole, I don’t think Chrome engineers do as good a job as they
>> could of actively soliciting signals. Members of the WebKit team at Apple
>> are usually happy to provide an opinion if asked, or at least point to
>> someone who can give an informed opinion. We also make sure to sync
>> internally on things like this, to be able to give relatively official
>> opinions.
>> 
> 
> Seconding Yoav's question - what would be the best way for us to write into
> the Blink process to do this?  I think "quote any member of the Webkit team
> you can get to make a statement in public" has multiple failure modes, so I
> want to make sure we're pointing to (as you put it) relatively official
> opinions.
> 
> 
>> It’s possible that this is a Blink process problem, and that maybe “no
>> signals” should be accompanied by a record of the lack of signal and/or
>> attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s
>> the intention of the signals section.
>> 
> 
> We just had a conversation on precisely this topic, and I expressed the
> concern that embedding a record of our attempts to solicit opinions might
> also be taken as shaming, which isn't our intent either.
> 
> I think I'm hearing:
> 
>   1. Blink needs to be more explicit about asking for signals.  It would
>   be good to have those as repeatable channels at the various other platform
>   implementation organizations.
>   2. Blink needs to be more intentional about notifying when features are
>   tracking to land, to put appropriate pressure on getting those signals
>   (positive or negative).
> 
> It’s especially concerning that WICG does not require either multiple
>> implementation experience (like W3C WGs do) or multiple implementor support
>> (like WHATWG does). As a result, single-implementation specifications with
>> no track to multi-engine implementation look exactly the same as incubation
>> projects with multi-implementor support.
> 
> I have to disagree with your concern, at least as an entry point.  The
> whole point of starting incubations is that they may not have multiple
> implementers interested in prototyping -but an incubation is not the end
> point.  Certainly, as specs graduate from WICG incubations into an
> appropriate WG (or the WHATWG) - their exit point from incubation - I would
> expect multiple implementers to support and to be working on
> implementations.

What’s lacking here is the clear indication between the two. For example, how 
does one supposed to figure out this intent to ship email was based on a 
feature not being reviewed by Mozilla or Apple? There should have been a clear 
indication that this is a single vendor feature in the spec itself.

I get that there needs to be some avenue to share ideas. But that avenue can’t 
be simultaneously something browser vendors use to claim that it’s a well 
accepted standard API.

> "No track to multi-engine implementation" can be only a matter of time and
> priority, also.  I'm not against declaring more directly/publicly what
> implementers are "supporting" (in quotes because there's not a precise
> definition here) any given incubation, if we can come up with a way to do
> so; would that help?
> 
> sometimes we end up with specs using the WICG “Community Group Draft
>> Report” logo while in an individual’s personal repo rather than in WICG.
>> 
> 
> As Yoav said, I think this is a bug - much like putting the W3C editor
> draft logo on a spec in a personal repo.  Misleading, at best.
> 
> 
>> I think these are process problems with WICG.
> 
> 
> I am strongly against making a higher bar than "multiple independent
> parties are interested" in order to start an incubation - because a bar
> such as "must have multiple implementers supporting" would mean the vast
> majority of incubations would be done effectively outside the community, in
> personal or corporate repos, with no early contribution IP commitment or
> outside engagement.
> 
> That said, I'm happy to talk about process improvements we can do in the
> WICG - for example, I proposed above that we enable implementers to tag
> their support in WICG repos.  Would that help?  Is there something else we
> should change?
> 
> -Chris
> (WICG co-chair, among other roles)

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

[Ryosuke Niwa]

> On Jun 9, 2015, at 3:55 PM, Zac Spitzer  wrote:
> 
> But what do end users or developers expect in terms of browser behavior in
> this situation?
> 
> The history api (or saving state to indexedDB) aren't going to solve the
> problem of reinitialization everytime the user switches back to a web app.
> Users expect them to behave like a native app.

That seems like a very platform/product specific issue to me.  I don't think we 
want W3C to be mandating how Web browsers should interact with the rest of the 
system.

> Chrome handles this as users and developers expect, web apps get paged out
> and require a reload depending on memory etc. Safari does it every single
> time

By Chrome, do you mean Android?  Again, this is really about the 
platform-dependent behavior we shouldn't be spec'ing in W3C.

Please file a new bug on our bug tracker at http://radar.apple.com

- R. Niwa

Re: [whatwg] "resize" events on elements

[Ryosuke Niwa]

> On Feb 23, 2015, at 11:34 PM, David Flanagan  wrote:
> 
> Yes, please! At a minimum I'd like to see this as a custom element
> lifecycle callback, but a more general resize event of some sort also seems
> like it would be useful. I've wanted this the most often when working with
> the canvas element.
> 
> This seems like the sort of thing that would have been proposed many times
> before. Is there history here? Good reasons that we do not already have a
> resize event?
> 
> If not done carefully, I fear that the introduction of a resize event will
> allow infinite layout loop bugs or a more benign situation where a user
> change in browser window size causes a ripple effect where many
> resize-sensitive components adjust their layout, affecting other
> components, and everything takes a while to settle down at the new size.

As I understand it, this is precisely why we haven't spec'ed such an event.  
It's very easily to end up with O(n^2) layout if each element's resize event 
handler triggers a new "layout" of elements.

> I'd also note that unlike regular events that propagate up the tree, resize
> notifications need to propagate down the tree from container elements to
> their children.

That's tricky.  CSS layout is mostly top-down so it's more natural for a parent 
element to be laid out first, and then notify its child that they need to be 
resized.  However, there is nothing that forces child elements not to "dirty" 
their parents' size again once scripts are involved.

The only mechanism I can think of that can solve both of above problems is 
along the line of firing "resize" event exactly once per element per rAF so 
that we would end up with at most two path layout instead of O(n^2) per rAF.  
i.e. elements can't get more resize events in response to a layout caused by an 
earlier resize event.  This is somewhat fragile though because it would mean 
that we can't have a hierarchy of elements that respond to parent's element 
resizing in response to "resize" events in a single frame.  But arguably, such 
a relationship would result in O(n^2) layout anyways so authors shouldn't be 
doing that.  Your canvas (or my inline SVG) use case would totally work under 
this restriction.

- R. Niwa

Re: [whatwg] "resize" events on elements

[Ryosuke Niwa]

> 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 notified when their size changes. 
> We've run into a number of scenarios where this is extremely useful, and is 
> otherwise difficult or annoying (e.g. checking your size on a timer).
> 
> The idea was to allow the resize event on elements. I don't really care what 
> the solution is, so maybe someone here can come up with a better idea (size 
> observers?). And of course there are a lot of details to be worked out.

I would like it be an async event on an element although we might want it to 
fire earlier than setTimeout(~, 0) to avoid FOC (maybe the same timing as 
rAF?).  I don't think end-of-microtask makes sense as that may force too many 
layouts.

- R. Niwa

Re: [whatwg] Event loop processing model, and current time

[Ryosuke Niwa]

> On Feb 23, 2015, at 5:26 PM, James Robinson  wrote:
> 
> On Mon, Feb 23, 2015 at 4:57 PM, Simon Fraser  wrote:
> 
>> https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9
>> says:
>> 
>> 1. Let now be the value that would be returned by the Performance object's
>> now() method
>> 2. Let docs be the list of Document objects associated with the event loop
>> in question…
>> ...
>> 4. For each fully active Document in docs, run the resize steps for that
>> Document, passing in now as the timestamp
>> ...
>> 
>> This makes no sense, as performance.now() is per-document (it’s relative
>> to the document start time), so passing the same value to all documents in
>> the browsing context is bogus.
>> 
>> What may be intended is to “freeze” the performance.now() time in all
>> documents before processing those documents, but give each document its own
>> performance.now() time.
>> 
> 
> That is the intent.  The algorithm should grab a timestamp for each
> document "at the same time" (which is really just a matter of grabbing one
> timestamp and applying the correct offset for each document).

In that case, step 1 should probably define a list of timestamps, not the 
value.  Alternatively, "now" should be defined for each document.

- R. Niwa

Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos

[Ryosuke Niwa]

On Nov 10, 2014, at 2:48 PM, Boris Zbarsky  wrote:

> On 11/10/14, 5:31 PM, Florian Rivoal wrote:
>> That said, the labeled control also maintains a list of references to the 
>> associated labels, so there is no particular difficulty involved in finding 
>> them.
> 
> The difficulty is not finding them.  The difficulty is efficiently updating 
> hover state on the set of ancestors of all the nodes involved, some of which 
> might still be in hover state when the control ceases to be.

Indeed.  It appears to me that this use case can be solved by the proposed 
:has() relational pseudo class as long as the author has structured so that the 
label is an ancestor of the input control it’s associated with: 
http://dev.w3.org/csswg/selectors4/#relational

Given that, I don’t find it compelling to natively support this behavior in the 
browser.

- R. Niwa

Re: [whatwg] Preloading and deferred loading of scripts and other resources

[Ryosuke Niwa]

On Sep 8, 2014, at 1:33 PM, Ian Hickson  wrote:

> 
> I got some feedback on my last e-mail to the effect that having the 
> proposal sandwiched between the rationale and the examples of how it would 
> be used made it hard to find, so I'm reproducing the proposal here 
> (slightly updated based on feedback):
> 
> ---
> These "loadable" elements:
> 
>   

Re: [whatwg] Preloading and deferred loading of scripts and other resources

[Ryosuke Niwa]

On Sep 8, 2014, at 10:54 PM, Ilya Grigorik  wrote:

> On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson  wrote:
> 
>>> The platform is missing a lower-level primitive (declarative and
>>> imperative) that is able to explain resource loading with the same
>>> expressive power as requests initiated by the browser itself.
>> 
>> That isn't a problem.
>> 
> 
> I don't follow. To me that *is* the core problem that we should solve first
> and ship as soon as possible: if we keep the surface area low, we can ship
> it quickly and let developers experiment and move the platform forward.
> Adding more layers of higher-level APIs only slows the deployment process.

What problem(s) are those developers going to solve with such a low level API
other than the use cases A through Z listed here?


> To be clear, I'm not against the core premise of unifying various import
> mechanisms, but to me that's a secondary goal -- good housekeeping, but not
> the problem that the actual web developers (not implementers) are actually
> up against today. And, at least personally, I think we should prioritize
> developer needs over implementers. That said, I don't think we're actually
> that far apart…

What are problems Web developers actually up against today?

Not having a low-level network API, on its own, isn’t a problem.
Please give us a concrete real world use case for which the proposed API 
doesn’t work.


>>> and it also hides requests from the preload scanner, which is a
>>> deal-break for performance.
>> 
>> That's why the proposal in this thread uses the existing import mechanisms
>> to define how the dependencies.
>> 
> 
> But restricts it to a subset of resource types. Granted, this is not an
> issue if you give me a generic way to load any resource, ala rel=preload.

Right.

>>> (2) We also need a declarative, content-type agnostic primitive to
>>> express resource loads, such that the preload scanner is able to pickup
>>> and processes these fetches on par with all other resources -- hence my
>>> rel=preload suggestion.
>> 
>> I don't disagree that we need a way to declarative way to import
>> non-browser-native resources (like some text file the script uses for
>> storing game level data or something). But I don't think we need a
>> redundant mechanism to import resource types that already have existing
>> import mechanisms. That's not a "primitive", it's just a redundant
>> mechanism.
>> 
>> I went into more detail on this very topic, considering a wide array of
>> options, in the big e-mail I sent recently:
>> 
>> 
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html
> 
> It's only redundant insofar as XHR is a redundant mechanism for loading
> arbitrary resources. There are cases where fetching an image / stylesheet /
> etc, via XHR is both a reasonable and a required step -
> {pre,post}processing, and so on. Moving forward, I think the intent is to
> explain resource loading via Fetch. I'm asking for a declarative Fetch
> that's preloader friendly and has the same expressive capabilities.

I think rel=preload gives us a declarative preloader friendly syntax for Fetch.

>>> Note that I'm looking for declarative syntax that allows me to set
>>> arbitrary fetch priorities - e.g. upgrade my JSON payload to high
>>> priority because I need it to render content on the screen. This is the
>>> part that we *need* to solve.
>> 
>> rel=preload with the proposal on this thread handles this fine, as far as
>> I can tell.
>> 
> 
> Yes, I think it's close! A few considerations to account for in the
> processing model, based on real-world use cases and feedback from the
> webperf group:
> - https://igrigorik.github.io/resource-hints/#preload
> - *https://igrigorik.github.io/resource-hints/#processing
> *
> 
> All I'm arguing for here is that the MVP for giving web developers the
> power to start solving these problems is rel=preload. Everything else is a
> nice to have. As a result, I'd love to uncouple rel=preload from the
> rest... Once/if the other mechanisms are ready, rel=preload would just
> inherit them as part of coverage of . As I said earlier, I don't
> think we're that far apart.

Which values of loadpolicy content attribute are you proposing to support?

- R. Niwa

Re: [whatwg] Fetch Objects and scripts/stylesheets

[Ryosuke Niwa]

On Jul 22, 2014, at 5:33 PM, Ian Hickson  wrote:

> On Tue, 22 Jul 2014, Ben Maurer wrote:
>> 
>> To follow this up with a concrete suggestion:
>> 
>> var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
>> myfetch.then(function(resp) {
>>  document.body.appendChild(resp.body.asStyleSheet());
>> });
>> ...
> 
> Why not:
> 
>   var mystyle = E('link', { rel: 'stylesheet', href: 'my.css', whenneeded: 
> true });
>   document.body.appendChild(mystyle);
>   var myfetch = mystyle.fetch;
>   ...
> 
> ...where "E()" is some mechanism to easily create new elements (we need 
> one of those regardless), and "whenneeded" is some attribute that controls 
> the load policy (and in this case, tells it to not load yet, since I 
> presume that's what you're going to do next with the "myfetch" variable)?
> 
> ("whenneeded" here is a placeholder. I don't expect to actually go with 
> that. I just used it because it's what I had proposed the last time this 
> came up.)
> 
> That seems like it'd be no more complicated, but would involve less new 
> API surface (not to mention fewer new ways to shoot yourself in the foot, 
> e.g. getting the 'fetch-as' value wrong), and wouldn't require us to come 
> up with a way to enumerate all the kinds of fetch in an API.

That seems like a reasonable approach to the problem at hand.  It still poses a 
question as to how we can add a similar API for other types of resources 
(videos, images, etc…).  Any thoughts on that?

- R. Niwa

Re: [whatwg] Effect on window.opener when navigating an existing window using window.open

[Ryosuke Niwa]

On Jul 2, 2014, at 5:43 AM, Bob Owen  wrote:

> On 2 July 2014 03:18, Ryosuke Niwa  wrote:
>> 
>> Could you point me to a specific test case that demonstrates the
> difference?
> 
> Sure, here you go:
> https://people.mozilla.org/~bowen/openerTest/openerTest.html
> 
> In IE you get "firstOpener" alerted both times, which is as spec.
> 
> In Firefox and Chrome "secondOpener" is alerted the second time.
> 
> I'm almost embarrassed to say that I don't have Safari to test against, but
> I believe it's the same as Firefox and Chrome.

Yes, our behavior is same as Firefox and Chrome.

I'm somewhat concerned about the backwards compatibility given behaviors of
Chrome, Firefox, and Safari match and only Internet Explorer matches the spec.

But perhaps it's red herring given this is such an unpopular property to begin 
with.

> I've got a fix for Gecko, but we're concerned that there might be some
> compat issues and I haven't had time to look into it.

Would you care to share the Bugzilla number for Gecko?

I just filed webkit.org/b/134726.

- R. Niwa

Re: [whatwg] Effect on window.opener when navigating an existing window using window.open

[Ryosuke Niwa]

On Jul 1, 2014, at 9:45 PM, Boris Zbarsky  wrote:

> On 7/1/14, 10:18 PM, Ryosuke Niwa wrote:
>> Could you point me to a specific test case that demonstrates the difference?
> 
> http://fiddle.jshell.net/t4sgd/show/
> 
> Chrome and Firefox alert "true"; IE alerts "false".  The spec says "false" 
> should be alerted.

On Jul 2, 2014, at 5:43 AM, Bob Owen  wrote:

> On 2 July 2014 03:18, Ryosuke Niwa  wrote:
>> 
>> Could you point me to a specific test case that demonstrates the
> difference?
> 
> Sure, here you go:
> https://people.mozilla.org/~bowen/openerTest/openerTest.html
> 
> In IE you get "firstOpener" alerted both times, which is as spec.
> 
> In Firefox and Chrome "secondOpener" is alerted the second time.
> 
> I'm almost embarrassed to say that I don't have Safari to test against, but
> I believe it's the same as Firefox and Chrome.
> 
> I've got a fix for Gecko, but we're concerned that there might be some
> compat issues and I haven't had time to look into it.
> 
> If I remember correctly the fix for WebKit was pretty straight forward, so
> if you would be able to take on the compat testing that would be fantastic.

Thanks for the examples!

- R. Niwa

Re: [whatwg] Proposal: navigator.cores

[Ryosuke Niwa]

On Jul 2, 2014, at 6:31 AM, Rik Cabanier  wrote:

> 
> On Wed, Jul 2, 2014 at 10:37 AM, Anne van Kesteren  wrote:
> On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier  wrote:
> > Since there are now 2 implementations, it should be added to the spec
> > instead of just being a wiki.
> 
> That depends on whether other vendors are objecting.
> 
> Looks like that is the case:
> https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ
> 
> That thread concluded with a "let's see how this feature is going to be used 
> before we commit".
> Blink and WebKit certainly are in favor. 


I'm not certain if that accurately reflects where the WebKit community stands.
There was a lot of contentious discussion on the webkit-dev thread [1] and 
Bugzilla [2]

I agree some people are in favor but I wouldn't say everyone is definitely in 
the favor.

Also, WebKit's implementation also caps the number of cores at eight
to mitigate some of the finger printing / privacy concerns raised.

[1] https://bugs.webkit.org/show_bug.cgi?id=132588
[2] https://lists.webkit.org/pipermail/webkit-dev/2014-May/thread.html#26511

- R. Niwa

Re: [whatwg] Effect on window.opener when navigating an existing window using window.open

[Ryosuke Niwa]

Could you point me to a specific test case that demonstrates the difference?

On Mar 3, 2014, at 3:04 AM, Bob Owen  wrote:

> Hi,
> 
> The spec at [1] and [2] seems to be fairly clear that if an existing window
> is navigated using window.open, by a browsing context that is not the
> original opener, then window.opener should remain unchanged.
> 
> Currently, Trident (and incidentally Presto) seems to have the correct
> behaviour, but Blink, WebKit and Gecko all change window.opener to the
> window of the browsing context that has just caused it to navigate.
> I believe this to be a very long standing difference (>10 years for Gecko
> and Trident)
> 
> I am proposing to change Gecko to match the spec, but I was advised to
> raise the issue here before going ahead.
> 
> Do people agree that window.opener should remain unchanged in this
> circumstance?
> 
> If agreed, looking at the code, this would seem to be a fairly simple
> change for WebKit and Blink as well.
> 
> Thanks,
> Bob
> 
> [1] 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-opener
> 
> [2] 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name

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

[Ryosuke Niwa]

On May 15, 2014, at 10:01 AM, Elliott Sprehn  wrote:

> On Tue, May 13, 2014 at 11:21 AM, Ian Hickson  wrote:
> 
>> I would feel more comfortable putting things on SVG, MathML, and HTML
>> explicitly.
>> 
> I don't think we want contenteditable in SVG or MathML. Almost all of the
> operations don't make sense. What does intending in SVG do? What does
> making something italic? What happens when you hit enter? We can't just
> insert a new line in SVG, does it add some space between all the shapes?
> Where does your caret actually appear?
> 
> We might want some new kind of Web Editing API, but
> contenteditable/execCommand are both pretty specific to HTML.

contenteditable isn't just for execCommand.  We could simply enable plaintext 
editing inside SVG text element for example.

However, I would like to know what use cases and problems Dirk is trying to 
solve by moving these attributes from HTMLElement to Element.  Dirk, could you 
elaborate on that?

- R. Niwa

Re: [whatwg] Proposal: Inline pronounce element (Tab Atkins Jr.)

[Ryosuke Niwa]

On Jun 6, 2014, at 12:04 PM, Charles McCathie Nevile  
wrote:

> On Fri, 06 Jun 2014 14:22:48 +0200, Koji Ishii  
> wrote:
> 
>> On Jun 5, 2014, at 22:08, Tab Atkins Jr.  wrote:
>> 
>>> On Thu, Jun 5, 2014 at 11:29 AM, Nils Dagsson Moskopp
>>>  wrote:
 Brett Zamir  writes:
 
> On 6/5/2014 3:05 AM, whatwg-requ...@lists.whatwg.org wrote:
>> 
>> On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris
>>  wrote:
> ...
>>> There is currently no other text-level semantic that I know of for
>>> pronunciation, but we have elements for abbreviation and definition.
>>> 
>>> As an initial suggestion:
>>> 
>>> iPad
>>> 
>>> (Where the `ipa` attribute is the pronunciation using the
>>> International Phonetic Alphabet.)
>>> 
>>> What are your thoughts on this,
> ...
>> This is already theoretically addressed by ,
>> linking to a well-defined pronunciation file format.  Nobody
>> implements that, but nobody implements anything new either, of course.
> 
> I think it'd be a lot easier for sites, say along the lines of
> Wikipedia, to support inline markup to allow users to get a word
> referenced at the beginning of an article, for example, pronounced
> accurately.
 
 Is there any reason one cannot use the  element for pronunciation?
 
 Example:
 
 Elfriede Jelinek (ɛlˈfʀiːdə ˈjɛlinɛk) 
 
>>> 
>>> That's adequate for visually providing the pronunciation, but I think
>>> the original request was for a way to tell screen readers and similar
>>> tools how to pronounce an unfamiliar word.
>> 
>> True, but one could still use  for its semantics, and visually use the 
>> CSS to hide the pronunciations:
>> 
>>  rp, rt, rtc { display: none; }
> 
> In general screen readers respect HTML. If you use display:none they will not 
> render that content. So please do not do that.
> 
> Besides, the information is normally useful to people who can see it too - or 
> who can partially see it.
> 
>> Screen readers may have supported reading text in  instead of its base 
>> text when they supported Japanese. At least some screen readers in Japan 
>> does this.
> 
> The common use case for Ruby in both chinese and japanese, as far as I 
> understand, is to provide pronunciation. I don't see why that would be 
> inappropriate in general.

I agree.  The whole idea of using ruby for other kinds of footnote-like 
annotations is rather red herring because that's not how ruby is used.  Given 
the presentation of ruby elements are now fully spec'ed by CSS, there's nothing 
that prevents authors from using other HTML elements such as span, or even add 
a new element for annotations.  Or perhaps adding some attribute on ruby 
indicating whether a given ruby text is used to annotate or to indicate 
pronunciation might be sufficient.

-  R. Niwa

Re: [whatwg] Proposal: navigator.cores

[Ryosuke Niwa]

On May 3, 2014, at 10:49 AM, Adam Barth  wrote:

> Over on blink-dev, we've been discussing [1] adding a property to navigator
> that reports the number of cores [2].  As far as I can tell, this
> functionality exists in every other platform (including iOS and Android).
> Some of the use cases for this feature have been discussed previously on
> this mailing list [3] and rejected in favor of a more complex system,
> perhaps similar to Grand Central Dispatch [4].  Others have raised concerns
> that exposing the number of cores could lead to increased fidelity of
> fingerprinting [5].
> 
> My view is that the fingerprinting risks are minimal.  This information is
> already available to web sites that wish to spend a few seconds probing
> your machine [6].  Obviously, exposing this property makes that easier and
> more accurate, which is why it's useful for developers.
> 
> IMHO, a more complex worker pool system would be valuable, but most systems
> that have such a worker pool system also report the number of hardware
> threads available.  Examples:
> 
> C++:
> std::thread::hardware_concurrency();
> 
> Win32:
> GetSystemInfo returns dwNumberOfProcessors
> 
> POSIX:
> sysctl returns HW_AVAILCPU or HW_NCPU
> 
> Java:
> Runtime.getRuntime().availableProcessors();
> 
> Python:
> multiprocessing.cpu_count()
> 
> In fact, the web was the only platform I could find that didn't make the
> number of cores available to developers.

FWIW, this property has been added to WebKit [1] and Blink [2] although that's 
not an indication of any browser actually shipping it for WebKit.

[1] http://trac.webkit.org/changeset/169017
[2] https://src.chromium.org/viewvc/blink?revision=175629&view=revision

- R. Niwa

Re: [whatwg] Bicubic filtering on context.drawImage

[Ryosuke Niwa]

On Mar 26, 2014, at 9:22 PM, Rik Cabanier  wrote:

> On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa  wrote:
> 
>> 
>> On Mar 24, 2014, at 8:25 AM, Justin Novosad  wrote:
>> 
>>> On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd  wrote:
>>> 
>>>> 
>>>> A list of resampling methods defined by the spec would be a great
>>>> overengineered (not in a bad way) solution, but I think you really
>>>> only need to worry about breaking existing apps - so providing an
>>>> escape valve to demand bilinear (this is pretty straightforward,
>>>> everything can do bilinear) instead of the 'best' filtering being
>>>> offered is probably enough for future-proofing. It might be better to
>>>> default to bilinear and instead require canvas users to opt into
>>>> better filtering, in which case a list of available filters would
>>>> probably be preferred, since that lets the developer do feature
>>>> detection.
>>>> 
>>>> I think we missed an opportunity to make filtering future-proof when it
>>> got spec'ed as a boolean. Should have been an enum IMHO :-(
>>> Anyways, if we add another image smoothing attribute to select the
>>> algorithm let's at least make that one an enum.
>>> 
>>> I'm not sure the spec should impose specific filter implementations, or
>>> perhaps only bi-linear absolutely needs to be supported, and all other
>>> modes can have fallbacks.
>>> For example.  We could have an attribute named imageSmoothingQuality.
>>> possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean
>>> bi-linear. Not sure which mode should be the default.
>> 
>> We could also have interpolateEndpointsCleanly flag that forces bilinear
>> or an equivalent algorithm that ensures endpoints do not get affected by
>> inner contents.
>> 
> 
> Is that to clamp the sampling to the source rect?
> http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is
> turned off which is a bit strange.
> 
> 
>> In general, it's better to define semantic based flags and options so that
>> UAs could optimize it in the future.  Mandating a particular scaling
>> algorithm in the spec. would limit such optimizations in the future.  e.g.
>> there could be a hardware that natively support Lanczos sampling but not
>> Bicubic sampling.
>> 
> 
> If it was an enum/string, an author could set the desired sampling method
> and if the UA doesn't support it, the attribute would not change.


The point I was trying to make isn't so much about some UA not supporting a 
particular sampling algorithm.  It's more about that the right/most-effective 
sampling algorithm depending on platform/hardware.  In general, UA is in a much 
better position to determine what sampling algorithm works best given the 
constraints such as smoothness and interpolating endpoints cleanly on a given 
hardware.

- R. Niwa

Re: [whatwg] Bicubic filtering on context.drawImage

[Ryosuke Niwa]

On Mar 24, 2014, at 8:25 AM, Justin Novosad  wrote:

> On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd  wrote:
> 
>> 
>> A list of resampling methods defined by the spec would be a great
>> overengineered (not in a bad way) solution, but I think you really
>> only need to worry about breaking existing apps - so providing an
>> escape valve to demand bilinear (this is pretty straightforward,
>> everything can do bilinear) instead of the 'best' filtering being
>> offered is probably enough for future-proofing. It might be better to
>> default to bilinear and instead require canvas users to opt into
>> better filtering, in which case a list of available filters would
>> probably be preferred, since that lets the developer do feature
>> detection.
>> 
>> I think we missed an opportunity to make filtering future-proof when it
> got spec'ed as a boolean. Should have been an enum IMHO :-(
> Anyways, if we add another image smoothing attribute to select the
> algorithm let's at least make that one an enum.
> 
> I'm not sure the spec should impose specific filter implementations, or
> perhaps only bi-linear absolutely needs to be supported, and all other
> modes can have fallbacks.
> For example.  We could have an attribute named imageSmoothingQuality.
> possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean
> bi-linear. Not sure which mode should be the default.

We could also have interpolateEndpointsCleanly flag that forces bilinear or an 
equivalent algorithm that ensures endpoints do not get affected by inner 
contents.

In general, it's better to define semantic based flags and options so that UAs 
could optimize it in the future.  Mandating a particular scaling algorithm in 
the spec. would limit such optimizations in the future.  e.g. there could be a 
hardware that natively support Lanczos sampling but not Bicubic sampling.

- R. Niwa

Re: [whatwg] for year input

[Ryosuke Niwa]

> On Mar 11, 2014, at 2:28 AM, Smylers  wrote:
> 
> Ryosuke Niwa writes:
> 
>>> On Mar 7, 2014, at 3:54 AM, Smylers  wrote:
>>> 
>>> An international website wanting a [year] ... could internally store
>>> all years using one particular system (say the Gregorian one), but
>>> allow input in other systems. This could be with a free-form text
>>> box with interpretation, validation, and error-handling on the
>>> server side, but that would be a substandard user interface. Better
>>> would be to use browser-side JavaScript either to perform the
>>> validation or to provide a year picker which only allows selecting
>>> valid years; regardless of the interface on this picker ― for
>>> instance, listing Japanese emperors ― it could set the value
>>> submitted with the form to be the equivalent Gregorian year.
>> 
>> This is why type=year would be useful so that UAs could present it in
>> accordance to the user preference.
> 
> It's only useful if there are actually sites which want to do this.
> 
>>> Are there many websites currently catering [for] Japanese years by
>>> offering such an interface? If so, it would make sense to create
>>>  such that browsers can offer this consistently,
>>> freeing authors from having to develop these for each site.
>> 
>> SMBC, the second largest bank in Japan, has an online account form
>> which asks the date of birth using Japanese calendar system. They
>> don't provide an option to type that in using the Gregorian calendar
>> at least in the Japanese version of their website.
>> 
>> Sony bank (moneykit.net) asks the date of birth using Gregorian
>> calendar but provides a conversion table from Japanese calendar
>> system: http://moneykit.net/visitor/account/account14.html
>> 
>> I'll note, however, that both of these use cases are better addressed
>> via type=date.
> 
> Yes, so they aren't actually demonstrating that  would
> be useful.
> 
> Also, both of those seem to be sites intended only for Japanese users.
> As such, a Japanese-specific year selection is sufficient for them; they
> can use  for the entire year, or possibly  for the era
> then  for the year within that era. Such sites
> wouldn't be trying to use  for a year in the first
> place, so the unsuitability of it for Japanese years doesn't matter.

It isn't.  Unfortunately, younger generations tend to be more comfortable with 
the Gregorian calendar while older generations tend to be more comfortable with 
Japanese era system.

This is why iOS allows users to pick either representation instead of always 
using either based on locale.

> The need for a widget which offers either Japanese or Gregorian
> interfaces for selecting a year, depending on the user's preference,
> then always submits it in a single defined way to the server, only
> really crops up on an international site which can expect users most
> familiar with each of those calendar systems.

Hence this is not true.

>>> However, that still wouldn't solve the problem of
>>>  putting commas in 4-digit page numbers.
>> 
>> Right.  But with if we had type=year, UAs could localize it
>> appropriately for this use case.
> 
> Indeed. But if  isn't otherwise useful, there may be a
> more generic way of addressing the ‘no commas in 4-digit years’ issue
> which also addresses 4-digit page numbers (and the like).
> 
> Cheers
> 
> Smylers
> -- 
> http://twitter.com/Smylers2

Re: [whatwg] for year input

[Ryosuke Niwa]

On Mar 7, 2014, at 3:54 AM, Smylers  wrote:

> Ryosuke Niwa writes [re-ordered]:
> 
>>> On Feb 19, 2014, at 7:36 AM, "Jukka K. Korpela" 
>>> wrote:
>>> 
>>> 2014-02-19 11:10, Smylers wrote:
>>> 
>>>> Jukka K. Korpela writes:
>>>> 
>>>>> The point is that year numbers aren't really "numbers" in a
>>>>> normal sense, any more than car plate numbers, credit card
>>>>> numbers, product numbers, or social security numbers are. Surely
>>>>> they can be regarded as numbers, but so can car plate numbers
>>>>> and the others.
>>>> 
>>>> Except that years do actually form a sequence, and it's possible
>>>> to perform maths on them; for instances, subtracting one year from
>>>> another yields a duration
>>> 
>>> Mathematically, you are right, but input types aren't based on
>>> general properties of quantities but on practical classification of
>>> input data. All the examples I gave, including year numbers, are
>>> normally input by typing the digits - in contrast with, say, using a
>>> color picker, a data picker, or a slider. And year numbers differ,
>>> as mentioned, from normal numbers as regards to conventional formats
>>> (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...).
>>> 
>>> So in the input process, a year number is not treated like a number.
>>> It typically appears when asking for year of birth or some other
>>> event (marriage, employment, etc.). The input check is normally
>>> against any non-digit data, the kind of thing we can do with
>>> pattern=...
>>> 
>>> Logically, one might say that since asking for a year is very often
>>> an alternative to asking for more specific data such as month or
>>> day, it should be treated as "date and time input" rather than text
>>> input with restrictions. But I don't see how this would be
>>> practically relevant. What else could  be other
>>> than reading some digits? There is the possibility of allowing
>>> two-digit numbers, with an implied century, but if that is
>>> desirable, authors can use >> deal with the implied century in their own code.
>> 
>> Let me point out that not every calendar uses simple 2-4 digit numbers
>> to denote years.
>> 
>> The Japanese era name calendar system, for example, requires an era
>> name such as Showa and Heisei associated with each year.
>> 
>> For example, I was born in Gregorian year 1986 but any Japanese
>> government document would say I was born in Showa 61.  My brother was
>> born in 1989 but, again, he must write "Heisei 1" instead on any
>> government form.
>> 
>> There are also even quite few banks and other organizations in Japan
>> that use the era name system for various forms and documents.
> 
> Yes, so for a Japanese organization using the era system,
>  would clearly be inappropriate for years.

Yes.

> An international website wanting a could use  and let
> users specify the year any way they want — Japanese eras, 2-digit years,
> Roman numerals, whatever. This could only realistically be stored as a
> string, and the only thing the website could do with it is display it
> again; it would be hard to sort by it, or perform restrictions based on
> the year, for instance. In this scenario, there's nothing special about
> the year so far as HTML is concerned.

I don't think that's a good solution because websites probably needed to use 
that year to do something.

> Or it could force all users to use Gregorian years, and anybody using a
> different system needs to convert their year themselves. At which point
>  works just fine.

That's also an inadequate solution as the conversion between two systems isn't 
easy.
It's not a simple subtraction or addition. Note that iOS natively support 
Japanese calendar system.

> Or the website could internally store all years using one particular
> system (say the Gregorian one), but allow input in other systems. This
> could be with a free-form text box with interpretation, validation, and
> error-handling on the server side, but that would be a substandard user
> interface. Better would be to use browser-side JavaScript either to
> perform the validation or to provide a year picker which only allows
> selecting valid years; regardless of the interface on this picker — for
> instance, listing Japanese emperors — it could set the value submitted
> with the form to be the equivalent Gregorian year.

This is why type=year would

Re: [whatwg] for year input

[Ryosuke Niwa]

Let me point out that not every calendar uses simple 2-4 digit numbers to 
denote years.

The Japanese era name calendar system, for example, requires an era name such 
as Showa and Heisei associated with each year.

For example, I was born in Gregorian year 1986 but any Japanese government 
document would say I was born in Showa 61.  My brother was born in 1989 but, 
again, he must write "Heisei 1" instead on any government form.

There are also even quite few banks and other organizations in Japan that use 
the era name system for various forms and documents.

- R. Niwa

> On Feb 19, 2014, at 7:36 AM, "Jukka K. Korpela"  wrote:
> 
> 2014-02-19 11:10, Smylers wrote:
> 
>> Jukka K. Korpela writes:
>> 
>>> The point is that year numbers aren't really "numbers" in a normal
>>> sense, any more than car plate numbers, credit card numbers, product
>>> numbers, or social security numbers are. Surely they can be regarded
>>> as numbers, but so can car plate numbers and the others.
>> 
>> Except that years do actually form a sequence, and it's possible to
>> perform maths on them; for instances, subtracting one year from another
>> yields a duration
> 
> Mathematically, you are right, but input types aren't based on general 
> properties of quantities but on practical classification of input data. All 
> the examples I gave, including year numbers, are normally input by typing the 
> digits - in contrast with, say, using a color picker, a data picker, or a 
> slider. And year numbers differ, as mentioned, from normal numbers as regards 
> to conventional formats (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...).
> 
> So in the input process, a year number is not treated like a number. It 
> typically appears when asking for year of birth or some other event 
> (marriage, employment, etc.). The input check is normally against any 
> non-digit data, the kind of thing we can do with pattern=...
> 
> Logically, one might say that since asking for a year is very often an 
> alternative to asking for more specific data such as month or day, it should 
> be treated as "date and time input" rather than text input with restrictions. 
> But I don't see how this would be practically relevant. What else could 
>  be other than reading some digits? There is the possibility 
> of allowing two-digit numbers, with an implied century, but if that is 
> desirable, authors can use  the implied century in their own code.
> 
> Yucca
> 

Re: [whatwg] Feedback on seamless iframe attribute

[Ryosuke Niwa]

On Feb 3, 2014, at 11:23 AM, Ben Vinegar  wrote:
> Ultimately, seamless doesn’t affect Disqus, because it only applies to
> iframes that share the same origin as the browsing context. Which is good,
> because we don’t want to use the seamless attribute anyways – it would let
> publishers manipulate the styles of our application, which besides being
> potentially dangerous, is not something we want them doing.

Right.

> But while we’re not interested in the style component of the seamless
> attribute, we – and probably all developers that hack on iframes – are
> interested in the resizing behaviour it introduces. Right now we deploy
> fairly complex code, both inside the iframed document, and on the parent
> document, to resize the iframe element when the iframed content changes
> size [2]. Every iframed application with dynamically-sized content does the
> same.

Yeah, this is a use case we deeply case about.

> To me, it’s crazy that it’s 2013 and there’s still no native way to have
> the browser automatically resize an iframe. And yet we have seamless. But
> it not only resizes: it adds all this other bundled behaviour, and strictly
> serves a fringe use case where somebody is distributing iframes on the same
> origin.

Indeed!  Let’s solve this problem.

> My suggestion is to split seamless into its three major parts: style
> inheritance, iframe resizing, and browsing context.  Let the iframed
> _document_ declare whether it opts into style inheritance and/or parent
> browsing context (the latter can already be achieved by  target=”_parent”>). Let the iframe _element_ declare whether it should
> auto-resize (e.g. ). This way each context permits the
> other party to have additional control over its document (e.g. the parent
> allows the iframe to be resized according to the iframed document’s
> content, the iframed document allows the parent to apply styles to it).
> Since the size of the iframe element could leak session information,
> perhaps the iframed document additionally specifies a header for permitting
> the behaviour (like ResourceTiming or CORS).

An alternative is to make web components work cross-origin.  I had a straw man 
proposed posted on WebApps WG at W3C last year:
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

We haven’t made much progress there yet but I believe we can solve your use 
case if we invented some CSS primitives to clip an element and limit style 
inheritances.

- R. Niwa

Re: [whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

On Oct 25, 2013, at 11:42 AM, Ian Hickson  wrote:

> On Tue, 15 Oct 2013, Ryosuke Niwa wrote:
>> Namely, in the following example, the first alert should be "true" as 
>> far as I read the specification.
>> 
>>  var a = false; 
>> 
>>  alert(a); /* or even setTimeout(function(){alert(a);},0); */ 
>> setTimeout(function(){alert(a);},10) 
> 
> Well, javascript: is a bit of a weird case. In fact I'm planning on 
> revamping how that's specced shortly:
> 
>   https://www.w3.org/bugzilla_public/show_bug.cgi?id=13720
> 
> But right now, the above should alert false. Let me walk through why.
> 
> First, we start in the event loop, with one thread running. It picks up a 
> parser task, the parser inserts the  with its attributes set, and 
> that leads us to:
> 
> # When an iframe element is inserted into a document, the user agent must 
> # create a nested browsing context, and then process the iframe attributes 
> # for the first time
> -- http://www.whatwg.org/specs/web-apps/current-work/#the-iframe-element
> 
> So, first we create the nested browsing context:
> 
> # When a browsing context is first created, it must be created with a 
> # single Document in its session history, whose address is about:blank,
> # [...]
> -- http://www.whatwg.org/specs/web-apps/current-work/#browsing-context

Am I correct in assuming that load event never fires for this about:blank page 
since it’s “both ready for post-load tasks and completely loaded immediately"?

If so, that doesn’t match the existing behaviors of major browser engines.  For 
example, Firefox logs 1 then 2 in the following example whereas Chrome and 
Safari log 2 and then 1:
var iframe = document.createElement('iframe');
iframe.onload = function () { console.log('2'); }
document.body.appendChild(iframe);
console.log('1’);

- R. Niwa

Re: [whatwg] inputmode feedback

[Ryosuke Niwa]

On Dec 6, 2013, at 5:30 AM, Michael[tm] Smith  wrote:

> [Maybe we should take this discussion off-list or talk about it some time
> soon over lunch or something. For now though, here are some comments.]
> 
> "Takayoshi Kochi (河内 隆仁)" , 2013-12-06 19:53 +0900:
> 
>> Just for a data point, lots of Japanese banks still make user type in
>> half-width katakana.
> 
> OK, but anecdotally my limited experience as a user with Japanese bank
> sites is that the ones I use (Mizuho and Mitsui Sumitomo) don't require
> half-width katakana input anywhere.
> 
> Anyway, as I guess you know, bank sites as a class (along with airline
> sites) are notorious for doing a lot of stupid things that are really bad
> for user experience -- to the point where I think bank sites as a class
> should really be considered a counter-example of good design.
> 
>> Here are some random examples:
>> 
>> http://www.tominbank.co.jp/for_kojin/mobile/topics_hankaku-kana.html
>>> 「受取人名（半角カナ）」は、半角30字以内で入力してください。
>> 
>> http://www.shinkin.co.jp/okayama/ibandhib/bizib/02_faq/faq_07.html
>>> これらのカナ略語は*全て半角文字で入力*して下さい。
>>> 実際の振込画面から振込先の会社名を入力する際は、*全て半角カナで入力*してください
>> 
>> http://www.yamanashibank.co.jp/anser-web/B-KM-009/help.html
>>> 半角30文字以内で入力してください
> 
> I see. So I concede that unfortunately such sites do seem to exist. But
> instead of just accepting that, I think we ought to be asking why and doing
> some general evangelism to make it clear that's bad practice and also doing
> some evangelism with specific sites to try to get them to quit doing that.
> 
> What I would seriously like to see instead is an example of even one single
> good thoughtfully-designed site that's actually requiring half-width kana
> input for some good reason. Just one.

The problem with banking websites is that they tend to use old 
mainframe/database that stores data
in half-width kana in the backend, and maximum length, etc… are different 
between full-width and
half-width kana characters. e.g. it's hard to explain to the users that ガ is 
considered as two characters
(as it will consist of ｶ and ﾞ) when it's visually one character.

Unfortunately, I can't think of a good way to convince major banks in Japan to 
use full-width kana
in their databases and inter-bank transactions.

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Dec 5, 2013, at 8:36 AM, Ryosuke Niwa  wrote:

> On Dec 5, 2013, at 8:28 AM, Ian Hickson  wrote:
> 
>> On Wed, 4 Dec 2013, Ryosuke Niwa wrote:
>>> 
>>> Now that I've implemented the new behavior in WebKit, I'm not certain 
>>> completely ignoring the form element pointer is the right behavior here.
>>> 
>>> That would mean that we'll allow nested form elements and isindex 
>>> element will create its own form element even if it's inside another 
>>> form element inside template element.
>>> 
>>> Is that behavior really desirable?
>> 
>> Why would it not be? I think the only reason it's not desireable outside 
>> of  is back-compat. If there's something I'm missing, though, 
>> let me know!
> 
> Okay.  If the only reason the current behavior exits was for backwards 
> compatibility, the change works great for me.

I've made the change in WebKit: http://trac.webkit.org/changeset/160182
and filed bugs against Gecko and Blink:
https://bugzilla.mozilla.org/show_bug.cgi?id=946585
https://code.google.com/p/chromium/issues/detail?id=326058

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Dec 5, 2013, at 8:28 AM, Ian Hickson  wrote:

> On Wed, 4 Dec 2013, Ryosuke Niwa wrote:
>> 
>> Now that I've implemented the new behavior in WebKit, I'm not certain 
>> completely ignoring the form element pointer is the right behavior here.
>> 
>> That would mean that we'll allow nested form elements and isindex 
>> element will create its own form element even if it's inside another 
>> form element inside template element.
>> 
>> Is that behavior really desirable?
> 
> Why would it not be? I think the only reason it's not desireable outside 
> of  is back-compat. If there's something I'm missing, though, 
> let me know!

Okay.  If the only reason the current behavior exits was for backwards 
compatibility, the change works great for me.

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Dec 4, 2013, at 11:01 AM, Ian Hickson  wrote:
> On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
>> On Dec 3, 2013, at 3:51 PM, Ian Hickson  wrote:
>>> On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
>>>> On Dec 3, 2013, at 10:42 AM, Adam Barth  
>>>> wrote:
>>>> 
>>>> Do we really need a stack?  Can't we set the form element pointer 
>>>> aside when we push the first template element and restore it when we 
>>>> pop the last template element?
>>> 
>>> We could; in fact that might be sufficient because when the template 
>>> is cloned, all the special associations are lost anyway, IIRC. So the 
>>> form element pointer would be useless anyway in the template on the 
>>> long run.
>> 
>> Right.  I also think that not associating form elements with forms 
>> inside/outside template elements might be more natural to authors given 
>> their inert nature.
> 
> Well, they're still associated with forms inside (e.g. if they are 
> children or have a form="" attribute).
> 
> I've changed the parser spec to ignore the form element pointer for 
>  and  inside .
> 
>   http://html5.org/r/8331

Now that I've implemented the new behavior in WebKit, I'm not certain 
completely ignoring the form element pointer is the right behavior here.
That would mean that we'll allow nested form elements and isindex element will 
create its own form element even if it's inside another form element inside 
template element.

Is that behavior really desirable?

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Dec 3, 2013, at 3:51 PM, Ian Hickson  wrote:

> On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
>> On Dec 3, 2013, at 10:42 AM, Adam Barth  
>> wrote:
>> 
>> Do we really need a stack?  Can't we set the form element pointer aside 
>> when we push the first template element and restore it when we pop the 
>> last template element?
> 
> We could; in fact that might be sufficient because when the template is 
> cloned, all the special associations are lost anyway, IIRC. So the form 
> element pointer would be useless anyway in the template on the long run.

Right.  I also think that not associating form elements with forms 
inside/outside
template elements might be more natural to authors given their inert nature.

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Dec 3, 2013, at 10:42 AM, Adam Barth  wrote:

> Did you mean to drop whatwg from the CC list?
> 
> On Tue, Dec 3, 2013 at 10:39 AM, Ian Hickson  wrote:
>> On Thu, 21 Nov 2013, Ryosuke Niwa wrote:
>>> 
>>> A start tag whose tag name is "isindex"
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#isindex
>>> 
>>> Right now, form element pointer is not null in the following example, so we 
>>> end up losing isindex element entirely.
>>> 
>>> ab
>> 
>> Hm. It's worse than that:  will drop the inner
>> , because the form element pointer is set.
>> 
>> So, there's several ways we could fix this. We could simply say 
>> isn't valid inside  and ignore the whole problem.
> 
> That seems bad for authors because I can imagine folks wanting to have
> a templated form.  :)
> 
>> Or, we could have a form element pointer stack that parallels the
>> template stack.
>> 
>> I guess the latter is best for authors. How do implementors feel about
>> adding a new stack for the template stuff?

Do we really need a stack?  Can't we set the form element pointer aside when we 
push the first template element
and restore it when we pop the last template element?

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

There is a related quirk with respect to the isindex element.

A start tag whose tag name is "isindex"
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#isindex

Right now, form element pointer is not null in the following example, so we end 
up losing isindex element entirely.

ab

Granted, isindex is a legacy element but it seems better to keep things 
consistent.

- R. Niwa

On Aug 13, 2013, at 7:08 AM, Adam Klein  wrote:

> On Tue, Aug 6, 2013 at 4:47 PM, Adam Klein  wrote:
>> On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking  wrote:
>>> On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein  wrote:
 On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking  wrote:
> As I recall it (it was ages since I dealt with this), the tricky case
> that you need to handle is this one:
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2432
> 
> In this case, web compatibility requires that the  is
> associated with the form. Specifically hidden  elements would
> often end up moved, but still had to show up in form.elements as well
> as get submitted along with the form.
 
 That case definitely makes sense to me, and I think it's fine to keep
 that behavior for compat. The only one I'm asking to change is the
 case when the  and  end up in different trees.
>>> 
>>> Sure, as long as you come up with a formalized algorithm for when
>>> there is an association and when there isn't. Keep in mind that by the
>>> time that the input-element is inserted, the form-element might have
>>> been moved elsewhere. We likely don't need the association in that
>>> case, but detecting that that has happened sounds tricky.
>> 
>> My concrete proposal would be something like this:
>> 
>> In step 4 of 
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token,
>> add a requirement that "intended parent" and the "form element
>> pointer" be part of the same "home subtree" (defined at
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).
> 
> For what it's worth, we're giving this a try in Blink
> (https://src.chromium.org/viewvc/blink?revision=155949&view=revision),
> as it's by far the safest fix for the related crashes. I'll update
> this thread if we run into any compat issues in the wild (or if we
> don't!).
> 
> - Adam
> 
>>> The way that Gecko currently works IIRC is that it creates the
>>> association any time it has seen a "" without seeing a
>>> "". And it breaks the association anytime an input-element's
>>> parent chain changes and the associated form-element is no longer in
>>> the parent chain.
>> 
>> This is basically the same thing Blink & WebKit do, with the caveat
>> that we also avoid associating s with elements inside
>> s (this is now reflected in step 4 of the algorithm, see
>> above).
>> 
>>> On a related note, when are you guys going to add a cycle collector or
>>> other not-plain-refcounting memory manager :-)
>> 
>> Yes, that would be nice :)
>> 
>> - Adam
>> 
>>> / Jonas
>>> 
> On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein  wrote:
>> Hixie opened my eyes last week to parser-association behavior of the
>> sort found at 
>> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428.
>> In that case, an  in a detached tree is associated with a
>>  in the main document. This causes badness in WebKit and Blink
>> because the association between the  and the  (e.g., as
>> exposed in the HTMLFormElement.elements collection) is only weakly
>> held to avoid reference loops (and thus memory leaks). And that
>> weakness occasionally results in crashes when one of these objects is
>> collected before the other.
>> 
>> While all modern HTML parser implementations I tested seemed to agree
>> on their treatment of the above example (they all return "1" as
>> elements.length), this feature doesn't strike me as terribly useful.
>> And for what it's worth, it doesn't seem to be present in legacy IE.
>> 
>> I'm interested what others would think about changing the parser to
>> only associate a  with an  if both are in the same "home
>> subtree" 
>> (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).
>> Or is there some deep web-compat reason for this parsing oddity?
>> 
>> - Adam

Re: [whatwg] The src-N proposal

[Ryosuke Niwa]

On Nov 17, 2013, at 4:49 AM, Timothy Hatcher  wrote:

> On Nov 16, 2013, at 11:30 AM, Tab Atkins Jr.  wrote:
> 
>> This entire discussion, for months, has been entirely about syntax.  I
>> don't think I've seen a single person talk about semantics, nor do I
>> think it would make much sense to do so.
> 
> Maybe semantics is the wrong word. I feel (and others agreed on webkit-dev) 
> that the "srcset" term better represents this and syntactically using a 
> delimiter instead of multiple attributes is more tenable.
> 
>> The aesthetic concerns *are* personal, as it's an opinion about
>> whether you think it looks good and is understandable or not.  Some
>> people like it, some people don't.  It's not a big deal.
> 
> It is a big deal. Humans need to use this for years to come. Settling on 
> something that is polarizing is a big deal.

Without starting a debate on what semantics or aesthetics mean, syntax is a big 
deal.  A bad syntax can totally kill a feature.

- R. Niwa

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

[Ryosuke Niwa]

On Nov 12, 2013, at 4:11 PM, Adam Barth  wrote:
> On Tue, Nov 12, 2013 at 12:08 AM, Jukka K. Korpela  wrote:
>> 2013-11-12 9:58, Adam Barth wrote:
>>> Unfortunately, we can't add new tags to head.  If the parser sees a
>>> tag it doesn't recognize in the head, it creates a fake body tag and
>>> pushes the tag down into the body.
>> 
>> But you could use ..., with a suitable value
>> for foobar, like x-imgset. This could even be handled with a polyfill in old
>> browsers (JavaScript code that reads such elements and interprets their
>> content).
> 
> Maybe there's a CSS solution to this problem?  Do we just need to make
> the preload scanner smarter about interpreting CSS?

In fact, I’d argue that CSS will be a better fit to address art direction use 
case since it’s purely presentational.

We could define some ways to list set of images that could be replaced for a 
given img element in HTML and then let CSS pick which one to use for example.

- R. Niwa

Re: [whatwg] The src-N proposal

[Ryosuke Niwa]

On Nov 11, 2013, at 5:53 AM, Ilya Grigorik  wrote:

> On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth  wrote:
> 
>>> I believe you're applying an inappropriately high standard of required
>>> agreement to this proposal, compared to what the usual required level
>>> is for something to be accepted.
>> 
>> If Blink ships src-N and WebKit ships srcset, we'll have a mess on our
>> hands.  Authors will end up using both.  If they do, they're likely to have
>> different behavior in different browsers, which is an interoperability
>> problem.
>> 
>> The best solution I see to the above constraints is to ship
>> device-pixel-ratio switching via srcset today and to continue to discuss
>> how to address the remaining use cases in the future.
>> 
> srcset is a cul de sac with respect to these goals. Let's look at our
> options:
> 
> (1) + srcset addresses resolution-switching.
> (2) + in theory, srcset provides basic facilities for viewport-switching -
> although none of the current implementations support it.
> (3) - srcset viewport-switching syntax is a disaster for real-world
> scenarios [1]
> (4) - srcset does not provide any easy way to extend itself for art
> direction
> 
> By contrast, src-N is a superset: it covers (1) and (2), with same syntax
> even; it addresses (3); it enables (4).
> 
> Viewport-switching is just as important as res-switching: ultimately both
> are about saving bytes, and both have similar footprint in terms of pixels
> and bytes shipped. Further, they're not independent problems. After all,
> the outcome is that we ship a single file based on both parameters, hence
> the two must work together well (-1 for srcset). Finally, UX matters too
> (art-direction) and this case must work together with the previous two (-1
> for srscet).
> 
> In short, whatever solution we adopt, it must address all three points in
> the long run -- this is not a problem with three independent pieces that
> can be solved by three independent specs. We have three inputs, and we have
> one output: download X... and I just don't see srcset addressing these
> criteria. If someone can show me how srcset can, in fact, do this in
> future, then I'd love to hear it.
> 
> We have Mozilla and RICG behind src-N, and I hope Blink can put its weight
> behind it also.. I hope we can all work with Webkit team to address their
> concerns and solve this problem once and for all. So far, as Tab has
> pointed out, the src-N concerns we've heard are all cosmetic, and I think
> those discussions are distracting us from the real conversation we should
> be having, which is... how is srcset planning to address its shortcomings
> in a better way than src-N?

We can modify the parsing algorithm so that it can support delimiters for 
example.

- R. Niwa

Re: [whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

On Oct 17, 2013, at 10:22 PM, Ryosuke Niwa  wrote:

> 
> On Oct 17, 2013, at 9:58 PM, Boris Zbarsky  wrote:
> 
>> On 10/18/13 12:39 AM, Ryosuke Niwa wrote:
>>> As far as I read the spec, the navigation happens synchronously.
>> 
>> It's worth defining "the navigation" in this context.  I assume you mean the 
>> invocation of 
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
>>  ?  If so, I agree that this is synchronous for iframes being added to the 
>> DOM as things are currently specced, as well as for @src changes on .
>> 
>> This algorithm then synchronously performs certain steps.  Specifically, 
>> checking for scroll-to-anchor and doing the scroll.  At least as far as I 
>> can tell.  I don't know why it keeps checking the "gone async" value in 
>> steps 11, 12, 15, since nothing in the algorithm sets it to true until step 
>> 16 as far as I can tell.  Is "gone async" some sort of persistent state 
>> attached to the navigation, as opposed to the local variable it seems to be 
>> at step 7?
>> 
>>> Perhaps step 15 on 
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
>>>  indicates the specification already mandates it to be asynchronous.
>> 
>> I can't tell what this specification is actually saying here, unfortunately. 
>>  Too much indirection.  :(
> 
> Yeah, I'm getting completely lost there.  Perhaps Ian could clarify what the 
> current specification is trying to say there.
> 
>> The main hard design constraint I know of here is that navigating frames to 
>> about:blank via appending them to the DOM should ideally not change which 
>> document scripts see in the frame (though it does in Gecko right now; as I 
>> said we consider that a bug).  Whether this is implemented via some sort of 
>> synchronous navigation-like thing or via navigation preserving the document 
>> already in the frame seems like more of an implementation/specification 
>> detail than an observable thing...
> 
> I see.  Indeed, Firefox yields "false" but Safari, Chrome, and IE all yield 
> "true" in the following example:
> 
> 
> var iframe = document.createElement('iframe');
> iframe.onload = function () { console.log('loaded'); }
> document.body.appendChild(iframe);
> console.log('appended');
> var doc1 = iframe.contentDocument;
> setTimeout(function () {
>   console.log(doc1 === iframe.contentDocument);
> }, 0);
> 
> 
> Here is the list of output each browser yields:
> Safari  / Chrome:
>   loaded
>   appended
>   true
> Firefox:
>   appended
>   false
>   loaded
> IE:
>   loaded
>   appended
>   true
> 
> IE's behavior is interesting because it's synchronous. However,
> 
> console.log('appended');
> yields
>   appended
>   loaded
> so IE might be behaving differently depending on whether the iframe is 
> inserted by the script or not.

My preference is to match Firefox's behavior, and special-case about:blank to 
navigate synchronously but fire load event asynchronously.
i.e. what Boris said she wants Firefox to do.

That's probably the most consistent & Web-compatible behavior we can get.

- R. Niwa

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

[Ryosuke Niwa]

On Oct 22, 2013, at 4:00 AM, Anne van Kesteren  wrote:

> On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky  wrote:
>> So it looks to me like in practice Element.getElementById could be quite a
>> bit faster than the equivalent querySelector call, for both the in-tree case
>> (where both can avoid walking the tree) and the out-of-tree case (where both
>> need to walk the tree).
>> 
>> Food for thought.
> 
> So do you think we should add getElementById() to ParentNode in DOM?

Why not to Element?

> It seems the advantages are that we can optimize it better than
> querySelector() because there is no selector parsing. And because
> there is no selector parsing, you can simply pass the value of an
> element's id attribute rather than escaping said value using CSS
> escape rules.
> 
> What it seems we lack is a clear need for either, but if the cost of
> implementing it is low, maybe it's worth it?

Because of HTMLCollection's name getter, all major browsers must be capable of 
a id+name lookup at every element (since Element has getElementsByTagName that 
returns a HTMLCollection).

- R. Niwa

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

[Ryosuke Niwa]

On Oct 18, 2013, at 1:50 PM, Ian Hickson  wrote:

> On Fri, 18 Oct 2013, Tab Atkins Jr. wrote:
>> On Fri, Oct 18, 2013 at 11:09 AM, James Greene  
>> wrote:
>>> I would also love to see `getElementById` added to the 
>>> HTMLElement/Element interface. It would be nice to capitalize on that 
>>> potential perf boost in jQuery as well.
>> 
>> There's no perf boost available for searching by id on an arbitrary 
>> element.  The reason you may get a better perf for the normal functions 
>> is that documents cache a map from id->element on themselves, so you 
>> just have to do a fast hash-lookup.  Arbitrary elements don't have this 
>> map (it would be way too much memory cost), so it'll fall back to a 
>> standard tree search, exactly as a querySelector would.
> 
> Well, you _could_ just use the element's document's hash lookup, then walk 
> up the tree from the matching node to see if you reach the element, and 
> only if you don't, then fall back on walking the tree. Assuming most such 
> calls are not failing, that would give you pretty good performance (O(N) 
> on the depth of the subtree, more or less).

That's more or less what WebKit does.  The only situation under which WebKit 
has to traverse the entire subtree is when there are multiple elements with the 
same id.  In fact, the name getter access on HTMLCollection cannot always be 
O(n) or worse for compatibility reasons so I would be surprised if any major 
browser didn't have a similar optimization implemented one way or another.  
Having said that, this is all implementation detail/dependent so I wouldn't 
focus too much on this arguing one way or another.

Regardless, I'm supportive of adding getElementById on Element as long as we 
don't expose getElementsBy* functions.

- R. Niwa

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

[Ryosuke Niwa]

On Oct 18, 2013, at 5:22 AM, Tim Streater  wrote:

> On 15 Oct 2013 at 01:18, Glenn Maynard  wrote: 
> 
>> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson  wrote:
> 
> [snip]
> 
>>>   document.getElementById(id)
>>> 
>>> ...becomes:
>>> 
>>>   document.querySelector('#' + escapeCSSIdent(id))
>>> 
>>> ...which is a lot less pretty and understandable, especially when you
>>> consider that many authors are actually coming from:
>>> 
>>>   document.all[id]
>>> 
>>> ...which is briefer than either, and still self-explanatory.
>>> 
>>> 
>>> I feel this is a case where we're not putting authors first, but are
>>> instead putting spec purity first.
> 
>> (Nothing about this discussion relates to "spec purity", whatever that
>> means.  My argument is that this function is useless legacy, and that
>> proliferating it to DocumentFragment seems to be for consistency's sake
>> only.)
> 
> It's not useless legacy, it's a simple API call that does what it says.
> 
> I have an array of table bodies, one of which I switch into the user's view 
> by unhooking the present one from the table and appendChild-ing the one the 
> user now wants to look at. It's irritating enough that to search one of these 
> tBodies for an id I have to temporarily hook it to a DocumentFragment without 
> then being forced to use an opaque API call to get the result I want.
> 
> Personally I'd vote for it being possible to search any object for an id, 
> never mind it having to be part of the DOM or attached to a fragment. How 
> about:
> 
>tbodyPtr.getElementById (id);
> 
> That might be too radical so I'd settle for getElementById and friends being 
> available on fragments. Then we'd have consistency.

I'm fine with exposing getElementById on DocumentFragment or on ShadowRoot 
because it returns exactly one element.

What I'm opposed to is exposing getElementsByTagName, etc... because they 
return a live HTMLCollection.  HTMLCollection is a horrible mess, and the use 
of it should be discouraged as much as possible.

- R. Niwa

Re: [whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

On Oct 17, 2013, at 9:58 PM, Boris Zbarsky  wrote:

> On 10/18/13 12:39 AM, Ryosuke Niwa wrote:
>> As far as I read the spec, the navigation happens synchronously.
> 
> It's worth defining "the navigation" in this context.  I assume you mean the 
> invocation of 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
>  ?  If so, I agree that this is synchronous for iframes being added to the 
> DOM as things are currently specced, as well as for @src changes on .
> 
> This algorithm then synchronously performs certain steps.  Specifically, 
> checking for scroll-to-anchor and doing the scroll.  At least as far as I can 
> tell.  I don't know why it keeps checking the "gone async" value in steps 11, 
> 12, 15, since nothing in the algorithm sets it to true until step 16 as far 
> as I can tell.  Is "gone async" some sort of persistent state attached to the 
> navigation, as opposed to the local variable it seems to be at step 7?
> 
>> Perhaps step 15 on 
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
>>  indicates the specification already mandates it to be asynchronous.
> 
> I can't tell what this specification is actually saying here, unfortunately.  
> Too much indirection.  :(

Yeah, I'm getting completely lost there.  Perhaps Ian could clarify what the 
current specification is trying to say there.

> The main hard design constraint I know of here is that navigating frames to 
> about:blank via appending them to the DOM should ideally not change which 
> document scripts see in the frame (though it does in Gecko right now; as I 
> said we consider that a bug).  Whether this is implemented via some sort of 
> synchronous navigation-like thing or via navigation preserving the document 
> already in the frame seems like more of an implementation/specification 
> detail than an observable thing...

I see.  Indeed, Firefox yields "false" but Safari, Chrome, and IE all yield 
"true" in the following example:


var iframe = document.createElement('iframe');
iframe.onload = function () { console.log('loaded'); }
document.body.appendChild(iframe);
console.log('appended');
var doc1 = iframe.contentDocument;
setTimeout(function () {
   console.log(doc1 === iframe.contentDocument);
}, 0);


Here is the list of output each browser yields:
Safari  / Chrome:
loaded
appended
true
Firefox:
appended
false
loaded
IE:
loaded
appended
true

IE's behavior is interesting because it's synchronous. However,

console.log('appended');
yields
appended
loaded
so IE might be behaving differently depending on whether the iframe is inserted 
by the script or not.

>> I'm still somewhat puzzled by the fact processing the iframe attributes 
>> synchronously navigates to a new url (which itself could be async?) whereas 
>> following a hyperlink simply queues a task to navigate:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks
> 
> Gecko currently has that behavior: iframe @src changes start a navigation 
> sync, while link clicks (and form submission) just post an event to start a 
> navigation.  I wonder whether the spec simply specified that behavior
> 
> The reason Gecko has the "post an event" behavior for link clicks is unclear 
> to me.  The blame goes back to the initial revision of 
> docshell/base/nsWebShell.cpp:
> 
>  1.1  1998-07-18 14:42
>  new
> 
> Not very helpful.  :(
> 
> All that said, I believe this stuff is all script-observable in the sense 
> that it causes aborting of the document and whatnot.  Worth checking 
> when/whether current UAs do that in the two cases.
> 
> -Boris

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Ryosuke Niwa]

On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni  wrote:

> On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson  wrote:
> 
>> WCAG 2.0 claims that "many platforms allow the user to customize the
>> rendering of this focus indicator", though I admit that I don't see any
>> references for this claim:
>> 
>>   http://www.w3.org/TR/WCAG-TECHS/G165.html
>> 
>> IBM similarly claims "users may customize the default indicator in Windows
>> to a brighter color":
>> 
>>   http://www-03.ibm.com/able/guidelines/web/webfocusvisible_aa.html#tech3
>> 
>> I haven't been able to support those claims. However, Win32 in particular
>> has some APIs for changing focus rings (see below for references).
>> 
> 
> If the user changes the focus ring's color and/or width, then
> drawSystemFocusRing should draw using that style.
> 
> The issue is when the application wants to draw its own focus ring - should
> the system sometimes override that and draw its own focus ring instead?
> That's the argument I don't buy.
> 
> Respecting the system focus ring color but ignoring the rest of the system
> palette makes no sense. Suppose the user has chosen white-on-black text
> with a yellow focus ring. The canvas normally draws a black-on-white GUI
> with red focus rings that are really easy to see. If the canvas calls
> drawCustomFocusRing and the system draws its yellow focus ring instead, it
> will actually be worse. So drawing the custom focus ring, in the absence of
> the rest of the information about the system palette, is not necessarily an
> improvement at all.
> 
> I think this feature was proposed with the best of intentions by people who
> misinterpreted how Windows system colors and styles work, and didn't think
> through all of the implications.
> 
> I am totally in favor of trying to provide a better experience for users
> who want a high-contrast theme and custom focus rings - I just don't think
> this API is the way to achieve that goal, and I think it would actually
> make things worse if user agents implemented it as specified.
> 
> Perhaps this shouldn't even be solved as part of canvas. Maybe we should
> add web apis to indicate that the user prefers a custom color scheme that
> could be used for rendering the whole page, not just canvas.
> 
> The name isn't ideal, it's true. I don't know what a better name should
>> be, though. It's really "let me know if I should draw a focus ring, and if
>> I should, then take the opportunity to also notify the accessibility
>> tools", which doesn't make for a very pithy method name.
>> 
> 
> What would you call it if it never draws, but just notifies the UI? I think
> we could call it notifyFocusRingPath or something like that. Or we go with
> the scrollPathIntoView idea.

or something like defineFocusableRegion/defineFocusableArea.

I'd much refer names that signify the fact these functions define focusable 
area/region than the fact
it may draw the focus ring if the element is already focused since authors need 
to call this function
on all focusable elements that are currently visible on the canvas.

If we were to implement this API in WebKit, I don't think we'll draw the focus 
ring synchronously either
(i.e. our implementation will be similar to what Dominic said Chrome does).

- R. Niwa

Re: [whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

On Oct 17, 2013, at 7:28 PM, Boris Zbarsky  wrote:

> On 10/17/13 6:14 PM, Elliott Sprehn wrote:
> 
> > frame = document.createElement('iframe');
> > document.body.appendChild(frame);
> > frame.contentDocument; // synchronously available
> 
> Yes, but at least in Gecko the frame.contentDocument you observe there is not 
> the same as what you'd observer after at trip through the event loop.  Again, 
> we consider this to be a bug.
> 
>> Also javascript: URLs are not async in Firefox:
> 
> They most certainly are.  I know because I made them so.  ;)

Indeed!

>> Presumably all this behavior is required by spec.
> 
> Whatever the spec requires can't match all UAs here, because UAs totally 
> disagree on details of this behavior.
> 
> This also means the spec might not be requiring anything particularly 
> sane  I suggest carefully reading it to find what it _does_ require right 
> now, then fixing it as needed.  ;)

As far as I read the spec, the navigation happens synchronously.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element
When an iframe element is inserted into a document, the user agent must create 
a nested browsing context, and then process the iframe attributes for the first 
time.
...
When the user agent is to process the iframe attributes, it must run the first 
appropriate steps from the following list:
...
If the value of the src attribute is the empty string, let url be the string 
"about:blank".

Otherwise, resolve the value of the src attribute, relative to the iframe 
element.

If that is not successful, then let url be the string "about:blank". Otherwise, 
let url be the resulting absolute URL.

If there exists an ancestor browsing context whose active document's address, 
ignoring fragment identifiers, is equal to url, then abort these steps.

Navigate the element's child browsing context to url.


Perhaps step 15 on 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
 indicates the specification already mandates it to be asynchronous.

If gone async is false, return to whatever algorithm invoked the navigation 
steps and continue running these steps asynchronously.

I'm still somewhat puzzled by the fact processing the iframe attributes 
synchronously navigates to a new url (which itself could be async?) whereas 
following a hyperlink simply queues a task to navigate:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks

- R. Niwa

Re: [whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

On Oct 15, 2013, at 7:02 PM, Ryosuke Niwa  wrote:
> I'm trying to make page loads on iframe always asynchronous in WebKit.  
> However, the current specification appears to indicate that the navigation 
> happens synchronously.
> 
> Namely, in the following example, the first alert should be "true" as far as 
> I read the specification.
> 
>  var a = false; 
> 
>  alert(a); /* or even setTimeout(function(){alert(a);},0); */ 
> setTimeout(function(){alert(a);},10) 

I’ll add that Firefox and Internet Explorer both load about:blank 
asynchronously.

e.g. the first alert in
 var a = false; 

 alert(a); /* or even setTimeout(function(){alert(a);},0); */ 
setTimeout(function(){alert(a);},10) 
will say “false” in both browsers whereas it says “true” on Safari and Chrome.

- R. Niwa

[whatwg] Avoiding synchronous iframe load

[Ryosuke Niwa]

Hi,

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

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

 var a = false; 

 alert(a); /* or even setTimeout(function(){alert(a);},0); */ 
setTimeout(function(){alert(a);},10) 

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

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

- R. Niwa

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

[Ryosuke Niwa]

On Sep 13, 2013, at 1:53 AM, Anne van Kesteren  wrote:

> On Fri, Sep 13, 2013 at 8:42 AM, Simon Pieters  wrote:
>> * XHR response (uses interface "Document" and is an "XML document", even for
>> text/html if I read the spec correctly)
> 
> I assumed :/ that HTML would do the marking. Let's consider this a bug.
> 
> It's not entirely clear to me what the suggestion from Ryosuke is. Is
> it to keep getters on HTMLDocument only and expose HTMLDocument only
> in browsing contexts created from text/html resources? And use
> Document everywhere else and have Document contain all the other
> members including (former) SVGDocument members? That setup would make
> sense to me anyway.

My proposal something along that line.  But HTMLDocument also has a bunch of 
other junk properties like embeds, plugins, scripts, compatMode, bgColor, 
fgColor, alinkColor, linkColor, vlinkColor, etc… We even have write() and 
writeln() there!

I don’t want to start adding all these legacy methods elsewhere.

- R. Niwa

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

[Ryosuke Niwa]

On Sep 12, 2013, at 2:00 PM, Ian Hickson  wrote:

> On Thu, 12 Sep 2013, Ryosuke Niwa wrote:
>> On Sep 12, 2013, at 11:43 AM, Ian Hickson  wrote:
>>> 
>>> So you also support having a Document descendant that is used for 
>>> Documents that have global scopes / browsing contexts / the works, and 
>>> one that is used for Documents that don't (e.g. createDocument(), 
>>> XHR), where the former has the named getter and the latter doesn't?
>> 
>> I think that's what I'm suggesting except that I'm suggesting to keep 
>> calling the former HTMLDocument.
>> 
>> As far as I checked, SVGDocument and alike don't have named getter 
>> either so I'd rather not introduce it any non-HTML document.
> 
> What's an "HTML document" in this world? Something served using text/html? 
> Something with a browsing context? Some combination thereof?

I'm not trying to invent anything new here. HTMLDocument as existed before the 
merge.

> SVGDocument is supposed to be merged into Document as well. The idea is to 
> not have any descendants of Document. The reason is that you can have 
> compound documents that need both the SVG and HTML (and MathML and FooML) 
> methods. There's no such thing as "non-HTML documents" now. Documents can 
> have SVG and HTML and mix it at will.

That's okay but there's no point in bringing in legacy features like named 
property in that new world.

Named properties impos a significant runtime cost, and we'd like to get rid of 
them as much as possible.
As such, I'm strongly opposed to supporting it in more places.

- R. Niwa

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

[Ryosuke Niwa]

On Sep 12, 2013, at 11:43 AM, Ian Hickson  wrote:

> On Tue, 13 Aug 2013, Ryosuke Niwa wrote:
>> On Jul 12, 2013, at 11:04 AM, Boris Zbarsky wrote:
>>> On 7/12/13 1:57 PM, Ian Hickson wrote:
>>>> On Thu, 14 Mar 2013, Anne van Kesteren wrote:
>>>>> On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky wrote:
>>>>>> On 3/5/13 3:30 PM, Ian Hickson wrote:
>>>>>>> On Tue, Mar 5, 2013 at 4:50 PM, Boris Zbarsky wrote:
>>>>>>>> 
>>>>>>>> I don't want to merge the prototype objects for Document and 
>>>>>>>> HTMLDocument, because I don't want to stick a named getter 
>>>>>>>> on every document.
>>>>>>> 
>>>>>>> I'd be fine with having a Document descendant that is used for 
>>>>>>> Documents that have global scopes / browsing contexts / the 
>>>>>>> works, and one that is used for Documents that don't (e.g. 
>>>>>>> createDocument(), XHR); would that address this issue?
>>>>>> 
>>>>>> It's one way to address it, yes...
>>>>> 
>>>>> Just to be clear, this works for Mozilla, as long as it's clearly 
>>>>> defined and other vendors are on board. Arv?
>>>> 
>>>> Having not heard any interest from anyone else, I haven't done 
>>>> anything. If there's movement here, let me know.
>>> 
>>> That's because other UAs are just silently ignoring the spec as 
>>> currently written, for the most part...
>> 
>> I concur with Boris's concerns.
> 
> So you also support having a Document descendant that is used for 
> Documents that have global scopes / browsing contexts / the works, and one 
> that is used for Documents that don't (e.g. createDocument(), XHR), where 
> the former has the named getter and the latter doesn't?

I think that's what I'm suggesting except that I'm suggesting to keep calling 
the former HTMLDocument.

>> Can we at least avoid having OverrideBuiltins on Document?
> 
> Do you mean in general? Wouldn't that be non-backwards compatible?

I'm using the old terminology here.  I meant on Document, not HTMLDocument as 
we do keep OverrideBuiltins for the latter.

>> Or can we keep HTMLDocument that just defines name getter?
> 
> When would it be used? Are you agreeing with the proposal above? Or do you 
> have something different in mind?

As far as I checked, SVGDocument and alike don't have named getter either so 
I'd rather not introduce it any non-HTML document.

- R. Niwa

Re: [whatwg] Prioritizing subresources (Was Script preloading)

[Ryosuke Niwa]

On Sep 3, 2013, at 11:06 PM, William Chan (陈智昌)  wrote:

> On Sep 3, 2013 8:00 PM, "Ryosuke Niwa"  wrote:
> >
> > On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌)  
> > wrote:
> >
> > > Hello folks. Sorry for the late response to several comments in this
> > > mega-thread, I've mostly been traveling/vacationing for the past 2 months.
> > > A teammate asked me to look at this in case I had comments. I don't know
> > > web dev issues very well, so I'm going to restrain myself from offering
> > > many opinions about the new proposals other than wow, all this dependency
> > > stuff looks complicated, but maybe it's worth it? I'll keep to some
> > > observations from a networking performance perspective, in case it's
> > > relevant to the discussion:
> > >
> > > * Any advantages the preloader currently gives is probably only going to 
> > > be
> > > magnified with HTTP/2. Browsers today will in key situations hold back
> > > lower priority resource loads, even after the resource has been discovered
> > > by the parser/preloader, in order to reduce network contention and
> > > prioritize resources. But with HTTP/2, the browser almost never has to do
> > > this since it can express the request priority in the HTTP/2 protocol
> > > itself, and let the server order responses appropriately.
> > > *  is great for resource discovery. Given the above
> > > observation, note that it has some deficiencies. Most obviously, it does
> > > not indicate the resource type. Browsers today can heuristically assign a
> > > priority based on the resource type (script/image/stylesheet/etc).
> > > Arguably, browsers could just use the filename extension as a hint to the
> > > resource type, and that'd get us most of the way there. In any case,
> > > Chromium, when it encounters  is going to assign the
> > > resource load the lowest priority level, and only when the parser
> > > encounters the actual resource via a 

[whatwg] Prioritizing subresources (Was Script preloading)

[Ryosuke Niwa]

On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌)  wrote:

> Hello folks. Sorry for the late response to several comments in this
> mega-thread, I've mostly been traveling/vacationing for the past 2 months.
> A teammate asked me to look at this in case I had comments. I don't know
> web dev issues very well, so I'm going to restrain myself from offering
> many opinions about the new proposals other than wow, all this dependency
> stuff looks complicated, but maybe it's worth it? I'll keep to some
> observations from a networking performance perspective, in case it's
> relevant to the discussion:
> 
> * Any advantages the preloader currently gives is probably only going to be
> magnified with HTTP/2. Browsers today will in key situations hold back
> lower priority resource loads, even after the resource has been discovered
> by the parser/preloader, in order to reduce network contention and
> prioritize resources. But with HTTP/2, the browser almost never has to do
> this since it can express the request priority in the HTTP/2 protocol
> itself, and let the server order responses appropriately.
> *  is great for resource discovery. Given the above
> observation, note that it has some deficiencies. Most obviously, it does
> not indicate the resource type. Browsers today can heuristically assign a
> priority based on the resource type (script/image/stylesheet/etc).
> Arguably, browsers could just use the filename extension as a hint to the
> resource type, and that'd get us most of the way there. In any case,
> Chromium, when it encounters  is going to assign the
> resource load the lowest priority level, and only when the parser
> encounters the actual resource via a 

Re: [whatwg] Script preloading

[Ryosuke Niwa]

Per IRC discussion, I misunderstood the timing at which these at which 
dependencies are executed.  Now I agree it's desirable to have two values for 
when needed as proposed by Ian in the original e-mail.

For other people following this thread's sake, a.js will execute immediately as 
soon as it's loaded in this example:


// later
document.scripts.b.execute();

whereas a.js doesn't get executed until b.js is loaded in this example:


// later
document.scripts.b.execute();

- R. Niwa

On Sep 3, 2013, at 2:49 PM, Ryosuke Niwa  wrote:

> Original proposal:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html
> 
> In order to address use cases incDependencies and decDependencies satisfied, 
> I'm going to add the following proposals:
> 
> I make one more change that in order for a dependency specified in "needs" to 
> be satisfied,
> "src" content attribute of the dependent script needs to match the value when 
> the script finished running.
> e.g. myscript.src = null leaves any dependency on myscript unsatisfied.
> 
> Also make "needs" IDL property take in any HTML element; e.g. adding an image 
> element to "needs" makes the script wait until the corresponding image 
> resource is loaded.
> 
> On Aug 27, 2013, at 2:55 PM, Ian Hickson  wrote:
> 
>> 
>> First, let's get down to use cases. Kyle did a great job of describing 
>> some key use cases:
>> 
>> On Wed, 10 Jul 2013, Kyle Simpson wrote:
>>> 
>>> [Use-case Q:] I am dynamically loading one of those social widgets that, 
>>> upon load, automatically scans a page and renders social buttons. I need 
>>> to be able to preload that script so it's ready to execute, but decide 
>>> when I want it to run against the page. I don't want to wait for true 
>>> on-demand loading, like when my user clicks a button, because of the 
>>> loading delay that will be visible to the user, so I want to pre-load 
>>> that script and have it waiting, ready at a moment's notice to say "it's 
>>> ok to execute, do it now! now! now!".
> 
> 
>  ... 
> 
>>> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B 
>>> relies on A. Both need to load in parallel (for performance), but A must 
>>> execute before B executes. I don't control A and B, so changing them is 
>>> not an option. This CMS plugin [wants] to wait for some 
>>> user-interaction, such as a button click, before executing the code. We 
>>> don't want there to be any big network-loading delay visible to the user 
>>> between their click of the button and the running of that plugin's code.
> 
> // CMS plugin 1
> var A = E('script', { src: 'A.js', prefetch: true });
> var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true });
> document.body.append(A, B);
> function sawUserInteraction() {
>  B.execute();
> };
> 
> 
>>> Another CMS plugin on this same page wants to load "A.js", "C.js", and 
>>> "D.js". This plugin doesn't know or care that the other plugin also 
>>> requests "A.js". It doesn't know if there is a script element in the 
>>> page requesting it or not, and it doesn't want to looking for it. It 
>>> just wants to ask for A as a pre-requisite to C and D. But C and D have 
>>> no dependency on each other, only a shared dependency on A. C and D 
>>> should be free to run ASAP (in whichever order), assuming that A has 
>>> already run [once] some user-interaction that initiates the load of A, 
>>> C, and D. This user interaction may be before the other plugin requested 
>>> A, or after it requested A.
> 
> // CMS plugin 2
> var A = E('script', { src: 'A.js', prefetch: true });
> var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true });
> var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true });
> document.body.append(A, C, D);
> function sawUserInteraction() {
>  C.execute();
>  D.execute();
> };
> 
>>> "A.js" can be requested relatively (via a  tag or just relative to 
>>> document root) or absolutely, or it might be requested with the 
>>> leading-// protocol-relative from, taking on whatever http or https 
>>> protocol the page has, whereas other references to it may specify the 
>>> prototcol.
>>&

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Sep 3, 2013, at 3:45 AM, Jake Archibald  wrote:

> On 31 August 2013 00:04, Ryosuke Niwa  wrote:
> 
>> It'll be much harder to implement a new dependency API that replies on CSS
>> selectors if we care about the performance at all.
>> 
> 
> Where does the performance issue come from? It would only need to be
> resolved once on node creation or insertion into the document (the latter
> of the two). It's only used for execution, downloads can still be triggered
> without resolving the selectors (eg, by a pre-scanner).


>From the fact selector matching is slow.  I'm opposed to adding selector 
>dependency unless there is a very important use case that can't be addressed 
>by referring to a script by an element id or a script filename.

- R. Niwa

Re: [whatwg] Script preloading

[Ryosuke Niwa]

Original proposal:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html

In order to address use cases incDependencies and decDependencies satisfied, 
I'm going to add the following proposals:

I make one more change that in order for a dependency specified in "needs" to 
be satisfied,
"src" content attribute of the dependent script needs to match the value when 
the script finished running.
e.g. myscript.src = null leaves any dependency on myscript unsatisfied.

Also make "needs" IDL property take in any HTML element; e.g. adding an image 
element to "needs" makes the script wait until the corresponding image resource 
is loaded.

On Aug 27, 2013, at 2:55 PM, Ian Hickson  wrote:

> 
> First, let's get down to use cases. Kyle did a great job of describing 
> some key use cases:
> 
> On Wed, 10 Jul 2013, Kyle Simpson wrote:
>> 
>> [Use-case Q:] I am dynamically loading one of those social widgets that, 
>> upon load, automatically scans a page and renders social buttons. I need 
>> to be able to preload that script so it's ready to execute, but decide 
>> when I want it to run against the page. I don't want to wait for true 
>> on-demand loading, like when my user clicks a button, because of the 
>> loading delay that will be visible to the user, so I want to pre-load 
>> that script and have it waiting, ready at a moment's notice to say "it's 
>> ok to execute, do it now! now! now!".


 ... 

>> [Use-case S:] One CMS plugin wants to load "A.js" and "B.js", where B 
>> relies on A. Both need to load in parallel (for performance), but A must 
>> execute before B executes. I don't control A and B, so changing them is 
>> not an option. This CMS plugin [wants] to wait for some 
>> user-interaction, such as a button click, before executing the code. We 
>> don't want there to be any big network-loading delay visible to the user 
>> between their click of the button and the running of that plugin's code.

// CMS plugin 1
var A = E('script', { src: 'A.js', prefetch: true });
var B = E('script', { src: 'B.js', needs: 'A.js', prefetch: true });
document.body.append(A, B);
function sawUserInteraction() {
  B.execute();
};


>> Another CMS plugin on this same page wants to load "A.js", "C.js", and 
>> "D.js". This plugin doesn't know or care that the other plugin also 
>> requests "A.js". It doesn't know if there is a script element in the 
>> page requesting it or not, and it doesn't want to looking for it. It 
>> just wants to ask for A as a pre-requisite to C and D. But C and D have 
>> no dependency on each other, only a shared dependency on A. C and D 
>> should be free to run ASAP (in whichever order), assuming that A has 
>> already run [once] some user-interaction that initiates the load of A, 
>> C, and D. This user interaction may be before the other plugin requested 
>> A, or after it requested A.

// CMS plugin 2
var A = E('script', { src: 'A.js', prefetch: true });
var C = E('script', { src: 'C.js', needs: 'A.js', prefetch: true });
var D = E('script', { src: 'D.js', needs: 'A.js', prefetch: true });
document.body.append(A, C, D);
function sawUserInteraction() {
  C.execute();
  D.execute();
};

>> "A.js" can be requested relatively (via a  tag or just relative to 
>> document root) or absolutely, or it might be requested with the 
>> leading-// protocol-relative from, taking on whatever http or https 
>> protocol the page has, whereas other references to it may specify the 
>> prototcol.
>> 
>> These plugins can't guarantee what ID's or classes they use are reliably 
>> unique without undue processing burden.
> 
> [I've trimmed the text Kyle wrote here, but also implicit in his 
> description, as I understood it, was that A.js should only run once even 
> if both plugins tried to load it.]
> 
>> [Use-case T:] I have two different calendar widgets. I want to pop one 
>> of them up when a user clicks a button. The user may never click the 
>> button, in which case I don't want the calendar widget to have ever 
>> executed to render. [...]




function showCalendar(which) {
 if (which == 'a')
   document.scripts.calA.execute();
 else
   document.scripts.calB.execute();
}


Neither Ian's nor my proposal fallbacks gracefully here :(

>> [Use-case U:] I have a set of script "A.js", "B.js", and "C.js". B 
>> relies on A, and C relies on B. So they need to execute strictly in that 
>> order. [Now], imagine they progressively render different parts of a 
>> widget. [...] I only want to execute A, B and C once all 3 are preloaded 
>> and ready to go. It's [...] about minimizing delays between them, for 
>> performance PERCEPTION.
>> 
>> [For example, one of them might start playing a video, and another might 
>> introduce the  slides for that video. You want all of the 
>> relevant scripts to be run at once, so there's no point where the page 
>> has a  element but doesn't have the .]





 // when we need it...
 do

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Aug 30, 2013, at 5:54 PM, Glenn Maynard  wrote:

> I don't like the name "jit", because it already has a different meaning when 
> talking about scripting.  If this was for CSS or WebVTT or something else 
> other than scripts, it wouldn't be as bad...
> 
> On Fri, Aug 30, 2013 at 7:22 PM, Ryosuke Niwa  wrote:
> I don't quite understand why we need two values for "whenneded".
> 
> Why can't we simply have "prefetch" (since we already use that term in the 
> link element) and "needs" (I'd prefer calling it "requires") content 
> attributes?
> 
> When a script element has the prefetch attribute, it doesn't execute until 
> execute() is called upon the element unless
> (i.e. the script is executed immediately when the script has been loaded) if 
> at least one of its dependencies is not a prefetch
> (i.e. doesn't have the "prefetch" content attribute).
> 
> I'm not sure what you mean (skipping the parenthetical this says "unless if", 
> so I'm not sure how to parse that), but "prefetch" sounds like something 
> different than "jit".

Yes.  "Prefetch" is like "noexecute" if there are no dependencies that require 
immediate execution.  But it behaves like "jit" if there are dependencies.

Example 1.



Neither A.js, B.js, nor C.js are executed until execute() is called on each 
element.

Example 2.



Both C.js and B.js are executed respectively once they're loaded since C.js 
requires B.js.

Example 2.



A.js, C.js, B.js are executed respectively because "B.js" requires "C.js" that 
in turn requires "A.js"

> The use case was "download several scripts, then execute them all at once".  
> I'm not sure about that use case, but a prefetch hint doesn't seem right for 
> that.  You'd end up downloading the scripts even if they're never used.

There was a use case for fetching a script without ever executing them until 
execute() is called.

I'll argue, however, that UAs should have the option NOT to fetch such a script 
immediately based on the network condition, bandwidth, etc...  That's why I 
like the name "prefetch" because it implies a weak requirement.

Another problem I'm interested in hearing Web developer's opinion is how we can 
manage the priority of resource requests.  e.g. scripts only used for some 
obscure feature on a page can be requested later;  Web browser should be able 
to prioritize requests for the page's main assets such as the tile image, web 
fonts, etc...

- R. Niwa

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Aug 30, 2013, at 4:36 PM, Garrett Smith  wrote:

> On 8/30/13, Ryosuke Niwa  wrote:
>> 
>> I don't think it'll be hard to add the media attribute on the script element
>> at least in WebKit.
>> 
>> It'll be much harder to implement a new dependency API that replies on CSS
>> selectors if we care about the performance at all.
>> 
> What is this in response to? What dependency API that relies on CSS
> selectors? (I'm assuming you mean relies and not replies, but still
> not sure what you mean).

Sorry, I meant to say "relies".  I was referring to the Jake's version of the 
dependency resolution mechanism as seen below:

On Aug 29, 2013, at 9:42 AM, Jake Archibald  wrote:
> I'm not sure it's possible to get into loops with this. I imagined
> dependency resolution to happen once, on element creation or adding to
> document (whichever happens latest). So with:
> 
> 
> 
> 
> …the first script would have zero dependencies, because the selector
> matches zero elements. The second would depend on the first, so the
> execution order is a.js, b.js. The thing I like about the selector thing is
> you can very easily get (almost) async=false behaviour:



Going back to Ian's proposal.

On Aug 27, 2013, at 2:55 PM, Ian Hickson  wrote:
> Here's a proposal that attempts to address all the use cases:
> 
> High-level overview:
> 
>   elements get a new whenneeded="" attribute, which delays the 
>  execution of the script until the <script> element's execute() method is 
>  called. (This essentially provides the same as the "preload" 
>  suggestions.)
> 
>  <script> elements also get a new needs="" attribute, which takes a list 
>  of URLs. A <script> won't run (even if you call execute()) until all the 
>  <script src=""> elements referenced by its needs="" attribute are 
>  themselves ready to run. For example:
> 
> <script src="b.js" needs="a.js">
> 
> 
> ...will execute a.js when it's ready, and only then execute b.js. "needs" 
> basically implies "async" if its needs aren't met when it first tries to run.
> 
> 

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Aug 30, 2013, at 9:08 AM, Yoav Weiss  wrote:

> On Tue, Aug 27, 2013 at 11:55 PM, Ian Hickson  wrote:
> 
>> On Thu, 11 Jul 2013, Yoav Weiss wrote:
>>> 
>>> I've recently contemplated the slightly related issue of adding the
>>> "media" attribute to 

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Aug 29, 2013, at 8:37 AM, Nicholas Zakas  wrote:

> When Kyle and I originally started pushing for a way to preload JavaScript 
> many moons ago, the intent was very simple: to allow the downloading of 
> JavaScript and execution of JavaScript to be separate. The idea being that 
> you should be able to preload scripts that you'll need later without 
> incurring the cost of parsing and execution at that point in time. There are 
> many examples of people doing this, the most famous being the Gmail mobile 
> approach of loading JavaScript in comments and then pulling that code out and 
> eval()ing it.
> 
> I still feel very strongly that this pattern is a necessary evolution of how 
> we should be able to load scripts into web pages. I just want a flag that 
> says "don't execute this now" and a method to say "okay, execute this now". 
> Allowing that flag to be set both in HTML and JavaScript is ideal.
> 
> The question of dependency management is, in my mind, a separate issue and 
> one that doesn't belong in this layer of the web platform. HTML isn't the 
> right spot for a dependency tree to be defined for scripts (or anything 
> else). To me, that is a problem to be solved within the ECMAScript world much 
> the way CSS has @import available from within CSS code. 

But why do you want an ability to say "don't execute this now" if there were no 
dependencies?  Loading an extra script file that's not needed immediately can 
add few hundred of milliseconds to the total page load time over a slow network 
connection.

To put it another way, I don't see why anyone wants to load a script and not 
execute it other than for the purpose of avoiding the network request at a 
later time.  However, if that were the main purpose of providing such a 
functionality, then we also need to address the issue of this load request 
needing to have a lower priority than other load requests that are vital for 
the page.  In fact, we might want to avoid sending the request of a script file 
altogether if the user isn't going to interact the parts of the page that needs 
such a script.

- R. Niwa

Re: [whatwg] Script preloading

[Ryosuke Niwa]

On Jul 13, 2013, at 5:55 AM, Andy Davies  wrote:

> On 12 July 2013 01:25, Bruno Racineux  wrote:
> 
>> On browser preloading:
>> 
>> There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
>> PreloadScanner and "responsive design" for mobile. Responsive designs
>> mostly implies that everything needed for a full screen desktop is
>> provided in markup to all devices.
>> 
>> 
> The pre-loader is a tradeoff, it's aiming to increase network utilisation
> by speculatively downloading resources it can discover.
> 
> Some of the resources downloaded may be not be used but with good design
> and mobile first approaches hopefully this number can be minimised.
> 
> Even if some unused resources get downloaded how much it matter?

It matters a lot when you only have GSM wireless connection, and barely loading 
anything at all.

> By starting the downloads earlier, connections will be opened sooner, and
> the TCP congestion window to grow sooner. Of course this has to be balanced
> against visitors who might be paying to download those unused bytes, and
> whether the unused resources are blocking something on the critical path
> from being downloaded (believe some preloaders can re-prioritise resources
> if they need them before the preloader has downloaded them)

Exactly.  I'd to make sure whatever API we come up gives enough flexibility for 
the UAs to decide whether a given resource needs to be loaded immediatley.



On Jul 12, 2013, at 11:56 AM, Kyle Simpson  wrote:

> My scope (as it always has been) put simply: I want (for all the reasons here 
> and before) to have a "silver bullet" in script loading, which lets me load 
> any number of scripts in parallel, and to the extent that is reasonable, be 
> fully in control of what order they run in, if at all, responding to 
> conditions AS THE SCRIPTS EXECUTE, not merely as they might have existed at 
> the time of initial request. I want such a facility because I want to 
> continue to have LABjs be a best-in-class fully-capable script loader that 
> sets the standard for best-practice on-demand script loading.


Because of the different network conditions and constraints various devices 
have, I'm wary of any solution that gives the full control over when each 
script is loaded.  While I'm sure large corporations with lots of resources 
will get this right, I don't want to provide a preloading API that's hard to 
use for ordinary Web developers.


On Jul 15, 2013, at 7:55 AM, Kornel Lesiński  wrote:

> There's a very high overlap between module dependencies and 

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

Since Gecko has already implemented this behavior, I've gone ahead and changed 
WebKit's behavior:
http://trac.webkit.org/changeset/154761

- R. Niwa

On Aug 26, 2013, at 7:09 PM, Boris Zbarsky  wrote:

> On 8/26/13 9:51 PM, Ryosuke Niwa wrote:
>> That's good to hear.  So we're definitely in agreement with respect to this 
>> new behavior.
> 
> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23073
> 
> -Boris

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

On Aug 26, 2013, at 6:51 PM, Ryosuke Niwa  wrote:

> 
> On Aug 26, 2013, at 6:35 PM, Boris Zbarsky  wrote:
> 
>> On 8/26/13 7:13 PM, Ryosuke Niwa wrote:
>>> https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
>>> IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 
>>> 7th test cases.
>> 
>> You must be testing Firefox 23 or earlier?  Firefox 24 or later passes all 
>> these tests.
> 
> Yes, I was testing on Firefox 23 .
> 
>> In any case, the 2nd, 4th, 6th, and 7th tests are about properties not 
>> disappearing when they should, so those are not relevant here as far as I 
>> can tell.
>> 
>> That said, looking at this more closely, it seems like you and I may be in 
>> violent agreement.  Right now the spec says:
>> 
>>  If an element listed in the form element's past names map is removed
>>  from the Document, then its entries must be removed from the map.
>> 
>> which is all the testcase above tests as far as I can tell, since it removes 
>> the control from the DOM after setting its @form.  The testcase doesn't test 
>> what happens when @form is set on a control without removing it from the DOM.
> 
> Thanks for pointing that out.  I somehow missed that statement.  I didn't 
> test the case of explicitly setting the form content attribute because IE10 
> doesn't seem to support the form content attribute on input elements.
> 
>> What happens in Firefox 24 and above is that when an element stops being 
>> form-associated with a form it is in fact removed from the past names map 
>> for that form.  I asked for a spec bug to be filed to that effect in 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=879319#c4 but I'm not sure that 
>> ever happened  :(
> 
> That's good to hear.  So we're definitely in agreement with respect to this 
> new behavior.
> 
>>> What I mean is the form content attribute of a form control element used as 
>>> in: myInputInput.setAttribute('form', 'myForm');
>> 
>> Ah, I see.  Yes, ok.  So in particular, the spec already requires that 
>> elements be removed from the past names map when removed from the DOM, so 
>> the only issue is with @form changes, and there is not likely to be much 
>> content relying on @form changes _not_ removing from the past names map.  I 
>> wholeheartedly agree.
> 
> Yes, I'm particularly concerned about the case where form is explicitly 
> changed.  With that, we can have an input element containing its owner form 
> element, along with all other crazy edge cases.

Oops, an input element containing its owner element is fine.  What's not fine 
is the case where an input element contains a form element whose past names map 
points back to the input element and the input element's owner isn't the same 
form element.

- R. Niwa

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

On Aug 26, 2013, at 6:35 PM, Boris Zbarsky  wrote:

> On 8/26/13 7:13 PM, Ryosuke Niwa wrote:
>> https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
>> IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th 
>> test cases.
> 
> You must be testing Firefox 23 or earlier?  Firefox 24 or later passes all 
> these tests.

Yes, I was testing on Firefox 23 .

> In any case, the 2nd, 4th, 6th, and 7th tests are about properties not 
> disappearing when they should, so those are not relevant here as far as I can 
> tell.
> 
> That said, looking at this more closely, it seems like you and I may be in 
> violent agreement.  Right now the spec says:
> 
>   If an element listed in the form element's past names map is removed
>   from the Document, then its entries must be removed from the map.
> 
> which is all the testcase above tests as far as I can tell, since it removes 
> the control from the DOM after setting its @form.  The testcase doesn't test 
> what happens when @form is set on a control without removing it from the DOM.

Thanks for pointing that out.  I somehow missed that statement.  I didn't test 
the case of explicitly setting the form content attribute because IE10 doesn't 
seem to support the form content attribute on input elements.

> What happens in Firefox 24 and above is that when an element stops being 
> form-associated with a form it is in fact removed from the past names map for 
> that form.  I asked for a spec bug to be filed to that effect in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=879319#c4 but I'm not sure that 
> ever happened  :(

That's good to hear.  So we're definitely in agreement with respect to this new 
behavior.

>> What I mean is the form content attribute of a form control element used as 
>> in: myInputInput.setAttribute('form', 'myForm');
> 
> Ah, I see.  Yes, ok.  So in particular, the spec already requires that 
> elements be removed from the past names map when removed from the DOM, so the 
> only issue is with @form changes, and there is not likely to be much content 
> relying on @form changes _not_ removing from the past names map.  I 
> wholeheartedly agree.

Yes, I'm particularly concerned about the case where form is explicitly 
changed.  With that, we can have an input element containing its owner form 
element, along with all other crazy edge cases.

It seems like Firefox 24 already implements the exact behavior I want in WebKit 
so I'll go ahead and try to change WebKit's behavior accordingly.

- R. Niwa

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

On Aug 26, 2013, at 4:13 PM, Ryosuke Niwa  wrote:

> 
> On Aug 26, 2013, at 3:53 PM, Boris Zbarsky  wrote:
> 
>> On 8/26/13 5:45 PM, Ryosuke Niwa wrote:
>>> I propose to change the specification to remove any elements that are no 
>>> longer associated with the form from the past names map:
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map
>> 
>> Are you sure this doesn't break web pages?  What do UAs do here?  What did 
>> they use to do?
> 
> https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
> IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th 
> test cases.
> 
>>> It's strange for elements to linger around forever in the past names map 
>>> after the element get associated with a new form element.
>> 
>> I agree, though it's an obvious consequence of certain past implementation 
>> strategies.
> 
> I think we overlooked it when we added the support for dynamically changing 
> the owner form element.
> 
>>> Since IE didn't support form attribute for a long time (or maybe still 
>>> hasn't?), I don't think there is any compatibility concern.
>> 
>> I'm not sure what this sentence is saying.
> 
> What I mean is the form content attribute of a form control element used as 
> in: myInputInput.setAttribute('form', 'myForm');
> 
>> form.foo works in IE last I checked.  So what are you saying IE didn't or 
>> doesn't support?
> 
> Yes. IE does have that behavior.  What IE doesn't is keeping a form control 
> element in the past names map of a form element once the control got 
> disassociated with the form element.
> 
> I think IE's behavior is much saner than what we've implemented in WebKit and 
> Gecko.

Let me clarify what I'm proposing again.  What I'm proposing is to remove 
elements from the past names map when those elements are disassociated from the 
form element to match IE's existing behavior as opposed to that of WebKit and 
Gecko.  It simplifies implementations and confines the effect of this legacy 
feature.

- R. Niwa

Re: [whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

On Aug 26, 2013, at 3:53 PM, Boris Zbarsky  wrote:

> On 8/26/13 5:45 PM, Ryosuke Niwa wrote:
>> I propose to change the specification to remove any elements that are no 
>> longer associated with the form from the past names map:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map
> 
> Are you sure this doesn't break web pages?  What do UAs do here?  What did 
> they use to do?

https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th 
test cases.

>> It's strange for elements to linger around forever in the past names map 
>> after the element get associated with a new form element.
> 
> I agree, though it's an obvious consequence of certain past implementation 
> strategies.

I think we overlooked it when we added the support for dynamically changing the 
owner form element.

>> Since IE didn't support form attribute for a long time (or maybe still 
>> hasn't?), I don't think there is any compatibility concern.
> 
> I'm not sure what this sentence is saying.

What I mean is the form content attribute of a form control element used as in: 
myInputInput.setAttribute('form', 'myForm');

> form.foo works in IE last I checked.  So what are you saying IE didn't or 
> doesn't support?

Yes. IE does have that behavior.  What IE doesn't is keeping a form control 
element in the past names map of a form element once the control got 
disassociated with the form element.

I think IE's behavior is much saner than what we've implemented in WebKit and 
Gecko.

- R. Niwa

Re: [whatwg] Comments on

[Ryosuke Niwa]

On Apr 22, 2013, at 12:38 PM, Ian Hickson  wrote:

> On Mon, 22 Apr 2013, Matt Falkenhagen wrote:
>> 
>> 1. Browsers that don't support  will show the content by 
>> default, unlike browsers that do. Should the spec be changed to make 
>> dialogs open by default (and use a "closed" instead of "open" 
>> attribute)? Or is there another easy way to degrade gracefully for older 
>> browsers?
> 
> Putting:
> 
>   dialog { display: none }
> 
> ...in the style sheet is enough, as far as I can tell. That or just not 
> putting the element in the DOM until you need it. (In practice, on the 
> short term, you're unlikely to use this in situations without CSS and JS.)
> 
> 
>> 2. Would naming the methods open/close or show/hide instead of 
>> show/close be more natural?
> 
> The current naming is based on window.showModalDialog() and 
> window.close(). I agree the naming is weird, but being consistent is 
> probably going to be more helpful on the long run.

But that's because we have window.open but not an equivalent of window.close 
for window.showModalDialog, right?

It seems more consistent to use show/hide or open/close as Matt suggested.

- R. Niwa

[whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

Hi all,

I propose to change the specification to remove any elements that are no longer 
associated with the form from the past names map:
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#past-names-map

It's strange for elements to linger around forever in the past names map after 
the element get associated with a new form element.  Since IE didn't support 
form attribute for a long time (or maybe still hasn't?), I don't think there is 
any compatibility concern.

The change makes the elements associated with the form element more consistent 
and easier to reason about.  We can make form[x].form === form an invariant for 
every x such that form[x] is a form control element.

- R. Niwa

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Ryosuke Niwa]

On Aug 22, 2013, at 1:59 AM, Anne van Kesteren  wrote:

> On Wed, Aug 21, 2013 at 8:19 PM, Alexey Proskuryakov  wrote:
>> FWIW, this is tracked for WebKit as 
>> .
> 
> I think Darin's comment about the server component makes sense. My
> remark was mostly as to what is exposed to JavaScript. I don't think
> we expose an API to measure the number of grapheme clusters in a given
> string at the moment and writing such a function might be rather hard.
> (Although if maxlength was redefined to work this way...)

Yeah, I do see a benefit in matching what JavaScript does.  However, that's not 
the most intuitive behavior for users.

> Considering end users makes sense too, but we should also consider
> what applications people want to write. From limited testing I believe
> Twitter currently counts Unicode scalar values. This is somewhat
> better than code units, but e.g. U+0041 U+030A still subtracts two
> from your 140 limit. (This also means the example in the specification
> that makes a jab at Twitter is technically incorrect.) (Not that
> Twitter's current control could be implemented with a plain  or
> .)

If measuring the number of code units is what the author wanted, then he/she 
could manually check inputElement.value.length.

As you've just pointed out. different websites use different encoding schemes 
and have different requirements for the number of bytes or sequence of code 
units they can store.  I don't think we can solve that problem in HTML.

- R. Niwa

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Ryosuke Niwa]

On Aug 19, 2013, at 4:30 PM, Ryosuke Niwa  wrote:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#maximum-allowed-value-length
> 
> Why is the maxlength attribute of the input element specified to restrict the 
> length of the value by the code-unit length?
> 
> This is counter intuitive for users and authors who typically intend to 
> restrict the length by the number of composed character sequences.  In fact, 
> this is the current shipping behavior of Safari and Chrome.
> 
> Can the specification be changed to use the number of composed character 
> sequences instead of the code-unit length?

Also, 
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute
 says "if the input element has a maximum allowed value length, then the 
code-unit length of the value of the element's value attribute must be equal to 
or less than the element's maximum allowed value length."

This doesn't seem to match the behaviors of existing Web browsers or 
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#maximum-allowed-value-length
 unless I'm misreading something.  Namely, the value attribute set in the 
markup or by script isn't automatically truncated at the element's maximum 
allowed value length.

The paragraph should be revised to mention and only mention that the maxlength 
attribute affects the validation and the user agents may prevent the user from 
typing more characters than the specified value.

- R. Niwa

[whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Ryosuke Niwa]

Hi,

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#maximum-allowed-value-length

Why is the maxlength attribute of the input element specified to restrict the 
length of the value by the code-unit length?

This is counter intuitive for users and authors who typically intend to 
restrict the length by the number of composed character sequences.  In fact, 
this is the current shipping behavior of Safari and Chrome.

Can the specification be changed to use the number of composed character 
sequences instead of the code-unit length?

- R. Niwa

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

[Ryosuke Niwa]

I concur with Boris's concerns.  Can we at least avoid having OverrideBuiltins 
on Document?

Or can we keep HTMLDocument that just defines name getter?

- R. Niwa

On Jul 12, 2013, at 11:04 AM, Boris Zbarsky  wrote:

> On 7/12/13 1:57 PM, Ian Hickson wrote:
>> Having not heard any interest from anyone else, I haven't done anything.
> 
> That's because other UAs are just silently ignoring the spec as currently 
> written, for the most part...
> 
> -Boris
> 

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

[Ryosuke Niwa]

On Jul 28, 2013, at 4:24 PM, Jonas Sicking  wrote:

> On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai  wrote:
>> 
>> I was just picturing lazy computing the list. You don't need to compute the
>> list until you query the length or index into the NodeList, at which point,
>> if it's a static NodeList, you compute the whole thing in one go. If all you
>> ever do is grab the iterator, then no need to compute the list. So, the
>> example you give above would not precompute.

How common is it for an author to call querySelectorAll and then NOT iterate 
over it?
If the author simply wanted the first element, then the author should be 
calling querySelector instead.

>> Now that I put it in writing, the obvious problem with this is that it's a
>> change in semantics. If you querySelectorAll and then modify the DOM before
>> reading the length or an index, then you get a different list. :(
> 
> It's not just a change in semantics, it's a change in behavior. To
> keep the same behavior you would have to make the static NodeList
> observe the DOM and precompute itself as soon as the DOM was modified.
> 
> I.e. static NodeLists would incur the same performance problems that
> Ryosuke expressed concern about that live NodeLists have.
> 
> So yeah, I don't think it's an option.
> 
> In general, I'm not a big fan of anything that adds capabilities to
> "all NodeLists". This has been brought up in the past when people
> suggested adding the ability to observe changes to "all NodeLists".
> 
> It's not at all obvious to me that in *all* situations where we use
> NodeLists that it is desired to be able to iterate the results lazily.
> Requiring that might force implementations to spend a lot of time
> implementing something that doesn't have use cases.
> 
> We should think of NodeLists as simple Arrays. And it's clear that we
> don't want to force any function that returns an Array to be able to
> lazily compute that Array using an iterator. Keep in mind that the
> laziness is observable, so it's not a valid implementation strategy to
> only do the lazyness where there are clear performance benefits.

Yeah.  We could copy-on-write; i.e. do not allocate a node list as an array 
until DOM is about to be modified.
But it's quite tricky to do this correctly.

What are specific use cases under which statically allocating a node list is 
lower?

- R. Niwa

Re: [whatwg] iterators intead of live NodeLists WAS: Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Ryosuke Niwa]

On Jul 28, 2013, at 10:29 AM, James Greene  wrote:

> I think it makes sense, too. That said, if the goal is to REPLACE the
> NodeIterator and TreeWalker APIs completely, it wouldn't be all that
> valuable for me as my most common use case has always been to get TEXT
> NODES from under a root node based on some CSS filtering of its ancestor
> nodes.

NodeIterator already has an ability to only include text nodes.

It appears to me that we can also add an ability to match a selector.

e.g.  var nodeIterator = document.createNodeIterator(root, 
NodeFilter.SHOW_TEXT, null, 'div a');

can find all text nodes under elements that match 'div a'.


On Jul 27, 2013, at 1:04 PM, Ojan Vafai  wrote:

> There are many places where we expose Sequence or NodeList that can't
> easily be replaced with hand-rolled DOM walking (e.g. getNamedFlows).
> 
> You could imagine NodeIterator taking a Sequence/NodeList as an
> argument to it's constructor instead of adding an iterator method, but I
> find the NodeIterator interface to be clunky and awkward.
> 
> I think the methods we'd want here are next, previous, first and last. That
> way you can walk the iterator forward or backward. This doesn't overlap
> well with NodeIterator's current API.

NodeIterator has nextNode() and previousNode() already.  Why can't we add 
firstNode() and lastNode()?


On Jul 27, 2013, at 11:25 AM, Ojan Vafai  wrote:

> Realized this should probably be a new thread...
> 
> 
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai  wrote:
> 
>> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking  wrote:
>> I think these are good points of what is lost by using static NodeLists. I
>> still feel pretty strongly though that these benefits don't outweigh the
>> costs. If we want to give people most of the benefits of live NodeLists
>> without the costs we could expose an iterator API:
>> 
>> var iterator = document.querySelectorAll('div').iterator(); <--- does some
>> magic to not precompute the whole list
>> while (let current = iterator.next()) { ... }
>> 
>> And next always does the walk from the current node. So, if you add a div
>> before the current node, this specific iterator won't hit it, but if you
>> add a div after it would. I'm not sure what should happen though if you
>> remove the node that's the current node. I think I'm OK with the iterator
>> just returning null for the next() call in that case.
>> 
> 
> Thinking more on this, I think we could make next() still work in the case
> where you remove the node by pointing current at the previous node in the
> tree. Then you could do things like:
> 
> while (let current = iterator.next()) { current.remove(); }
> 
> This gets the performance benefits of live NodeLists, I think meets the

What happens when you remove the previous node during the iteration?

- R. Niwa

Re: [whatwg] inputmode feedback

[Ryosuke Niwa]

On Aug 12, 2013, at 11:28 PM, Yoichi Osato  wrote:

> I have questions about some inputmode attributes.
> In the desktop case, full-width-latin, kana and katakana look to intend
> user local IME. Right?
> I think whether IME is on or off is very important to user because some IME
> have state and show some window to input character.
> It is much different from alphabetic direct keyboard input.
> See
> https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section
> At least Chinese and Korean IME have state.
> In this point we should add attributes corresponding to chinese and korean.
> I don't know whether there are any other such a IME but I think many non
> English native people input in alphabet or hir/her native language.
> So should we add "native" attribute?

I think we need to separate the use case for controlling IME mode and hinting 
UA as to which type of text/script will be entered as Mounir suggested in the 
original email.

And I agree that we need to address Chinese and Korean IME use cases if we're 
adding Japanese IME use cases.  Also, IME behavior is very different depending 
on whether you're using pinyin or zhuyin/bopomofo in Chinese IME so we might 
need to differentiate those two as well.


On Mar 1, 2013, at 7:30 AM, Mounir Lamouri  wrote:
> On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote:
>> That said, even though authors of web apps may want to force the IME
> mode or
>> its script mode for user's sake, it may cause user's confusion as they are
>> so accustomed to change mode manually where such mode is required.
>> So if a web app sets some mode, the user may toggle it back to unintended
>> mode
>> and get frustrated.
> 
> I tend to agree. In one hand, I believe that users might get irritated
> if they can't control the inputmode but in another hand, forcing it
> might fulfil use cases where authors use Javascript to force a user to
> type in uppercase for example (that happens in a few forms).

On the other hand, inputmode is supposedly only a hint, right?   It doesn't 
affect the validation state of input elements.  Given that, how does it address 
such a use case?

> On 21/02/13 01:14, Ryosuke Niwa wrote:
>> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri 
> wrote:
>>> To conclude, Mozilla is interested in implementing this set of keywords:
>>> verbatim, text, name, prose and digit (or numeric).
>> 
>> Why is name not an input type?
>> 
>> How does one decide whether a given semantics should be introduced as
> a type or a mode?
> 
> I tend to prefer  over  type='name'> because , for the moment would be
> nothing else but a text field with an address book autocompletion. I
> would prefer to have 'tel' that way instead of having it a type FWIW.

But isn't type=email also a text field with autocompletion, no?  I agree that 
the UI might be similar on desktop browsers, but it could be completely 
different on mobile operating systems where UA could show a custom keyboard 
suitable to type in human names as opposed to arbitrary text.

How is that different from type=email where UA is supposed to assist user type 
in an email address?  It's not like we do a rigorous pattern matching to 
validate email addresses either.

- R. Niwa

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

[Ryosuke Niwa]

On Aug 8, 2013, at 7:29 AM, Jukka K. Korpela  wrote:

> 2013-08-08 2:57, Ryosuke Niwa wrote:
> 
>> On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela 
>> wrote:
> [...]
>>> But regarding the effect of language markup on fonts, the effect is
>>> limited to situations where the font is not specified in a style
>>> sheet. This is a rather uncommon scenario these days; authors are
>>> more than eager to set fonts.
>> 
>> Do you have actual statistics to support this point?
> 
> No, it’s just an impression from looking at numerous pages and their coding 
> as well as views presented in authors’ forums.
> 
>> As far as I
>> checked, neither baidu.com nor yahoo.com.tw seems to explicitly
>> specify a Chinese font.
> 
> They both have font-family settings, slightly different, but basically the 
> most common (sorry, no statistic on this either) setup that uses Arial 
> (possibly with Helvetica as second option, which does not change much). So, 
> granted, they don’t specify a Chinese font in the sense of including any 
> specific fonts containing CJK characters in the font-family list.
> 
> Baidu doesn’t set lang either, so they seem to be accepting, for any 
> characters not covered by Arial, whatever happens to be in each browser’s 
> list of fallback fonts, when no information about content language is 
> available. Yahoo.com.tw sets lang="zh-tw", so they do care, but only to the 
> extent that the fallback font should be one intended for Traditional Chinese.
> 
> So the lang markup may affect fonts, but only under some conditions. And if 
> you care about fonts, as an author, then an explicit list of font 
> alternatives has better chances of creating the desired result.

That's not a practical solution because we can't possibly know the list of 
Chinese & Japanese fonts available by default in all operating systems.

>>> It is true that they might specify a font list where none of the
>>> fonts supports some characters that might be entered, and then a
>>> fallback font would be used. However, using “annotations”
>>> (presumably, lang attributes, along with extra  elements when
>>> needed) does not sound like a feasible approach to this.
>> 
>> Whether it’s feasible or not, that’s what we have been doing due to
>> the Han unification.  If we could, we’ll undo the Han unification and
>> use different glyphs for each character but we can’t do that at this
>> point in time.
> 
> If a page contains texts to be rendered using different forms (Traditional 
> Chinese, Simplified Chinese, Japanese, Korean) for Han characters, you will 
> need to control the rendering somehow. Using lang markup might be 
> theoretically most adequate, but it’s indirect and less effective than just 
> setting different fonts (via font-family lists that contain reasonably many 
> alternatives).

Controlling the rendering isn't the goal here.  The point is to use the correct 
glyph in each language so that each character is recognizable by users.  Again, 
specifying a font name is not a practical solution as authors have no way of 
knowing the list of Chinese & Japanese fonts provided by all current and future 
operating systems.

> But even if lang attributes are used, I don’t think the issue has much 
> relevance to the original question here. A DOM attribute that returns the 
> language of a node would be useful for the purpose only if you intend to 
> affect rendering via JavaScript.

No.  The point is that any code that attempts to move or copy contents must 
preserve the effective value of the lang attribute.

- R. Niwa

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

[Ryosuke Niwa]

On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela  wrote:

> 2013-08-02 2:43, Ryosuke Niwa wrote:
> 
>>> Are you saying that for HTML contenteditable-based editors that want to
>>> support drag-and-drop editing, they need to be able to annotate the
>>> outgoing HTML fragment with the effective language so that when it's
>>> embedded somewhere, the right fonts get used?
>> 
>> Yes, but not just for drag and drop.
> 
> This would mean that the editor would have to guess the language from the 
> text or ask the user to specify it. This is not as unrealistic as it may 
> first seem. Microsoft Word does such things, sometimes getting things right, 
> often messing things up. It typically detects change of language too late, 
> and often infers language from keyboard settings, making it rather impossible 
> to use a multilingual keyboard easily.
> 
> But regarding the effect of language markup on fonts, the effect is limited 
> to situations where the font is not specified in a style sheet. This is a 
> rather uncommon scenario these days; authors are more than eager to set fonts.

Do you have actual statistics to support this point?  As far as I checked, 
neither baidu.com nor yahoo.com.tw seems to explicitly specify a Chinese font.

Also, I have just recently experienced the font type change on Gmail when I was 
conversing with a native Chinese speaker.  Her mail client used Chinese fonts 
before Japanese fonts whereas mine had Japanese fonts before Chinese fonts.

> It is true that they might specify a font list where none of the fonts 
> supports some characters that might be entered, and then a fallback font 
> would be used. However, using “annotations” (presumably, lang attributes, 
> along with extra  elements when needed) does not sound like a feasible 
> approach to this.

Whether it’s feasible or not, that’s what we have been doing due to the Han 
unification.  If we could, we’ll undo the Han unification and use different 
glyphs for each character but we can’t do that at this point in time.

- R. Niwa

Re: [whatwg] Form-associated elements and the parser

[Ryosuke Niwa]

On Aug 6, 2013, at 2:01 PM, Adam Klein  wrote:

> Hixie opened my eyes last week to parser-association behavior of the
> sort found at 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428.
> In that case, an  in a detached tree is associated with a
>  in the main document. This causes badness in WebKit and Blink
> because the association between the  and the  (e.g., as
> exposed in the HTMLFormElement.elements collection) is only weakly
> held to avoid reference loops (and thus memory leaks). And that
> weakness occasionally results in crashes when one of these objects is
> collected before the other.
> 
> While all modern HTML parser implementations I tested seemed to agree
> on their treatment of the above example (they all return "1" as
> elements.length), this feature doesn't strike me as terribly useful.
> And for what it's worth, it doesn't seem to be present in legacy IE.

What is the behavior of the old IE?

- R. Niwa

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

[Ryosuke Niwa]

On Jul 26, 2013, at 11:20 AM, Ian Hickson  wrote:

> On Wed, 24 Jul 2013, Ryosuke Niwa wrote:
>> On Jul 16, 2013, at 11:25 AM, Ian Hickson  wrote:
>>> On Tue, 16 Jul 2013, Takayoshi Kochi (河内 隆仁) wrote:
>>>> 
>>>> IIUC WebKit uses internally node's language to determine which font 
>>>> to use to render text, e.g for Han unification 
>>>> (https://en.wikipedia.org/wiki/Han_unification) WebKit has to choose 
>>>> a proper glyph depending on its lang attribute for the same Unicode 
>>>> codepoint.
>>> 
>>> Sure, but internal UA uses aren't use cases for the Web.
>>> 
>>> The use cases Peter gave over the weekend are valid, though.
>> 
>> The fact browsers use the "effective" language for font selection is 
>> very relevant in HTML editing. For example, consider the following 
>> document:
>> 
>> 
>> 
>> 僧廐埩
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> If you were to get the innerHTML of #source and insert it into 
>> #destination, the effective language changes from Chinese and Japanese 
>> and the three characters transform their shapes because browsers will 
>> use different fallback fonts.
> 
> It's unclear to me what use case you are describing here.
> 
> Are you saying that for HTML contenteditable-based editors that want to 
> support drag-and-drop editing, they need to be able to annotate the 
> outgoing HTML fragment with the effective language so that when it's 
> embedded somewhere, the right fonts get used?

Yes, but not just for drag and drop.

> This seems like something that browsers should just do automatically for 
> copy-and-paste and drag-and-drop, I wouldn't want to require that every 
> contenteditable-based editor have to reimplement this. That seems like a 
> lot of redundant work, and in particular, seems to be work that most 
> editor implementors would forget. If the browsers just did the annotation 
> automatically, then this would work even in editors whose implementors 
> didn't worry about i18n.

How are browsers supposed to do this if the author was simply using innerHTML?

I don't see how we can automatically annotate innerHTML.

- R. Niwa

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

[Ryosuke Niwa]

On Jul 16, 2013, at 11:25 AM, Ian Hickson  wrote:

> On Tue, 16 Jul 2013, Takayoshi Kochi ($B2OFb(B $BN4?N(B) wrote:
>> 
>> IIUC WebKit uses internally node's language to determine which font to use
>> to render text,
>> e.g for Han unification (https://en.wikipedia.org/wiki/Han_unification)
>> WebKit has to choose
>> a proper glyph depending on its lang attribute for the same Unicode
>> codepoint.
> 
> Sure, but internal UA uses aren't use cases for the Web.
> 
> The use cases Peter gave over the weekend are valid, though.

The fact browsers use the "effective" language for font selection is very 
relevant in HTML editing. For example, consider the following document:



$BANV}$(D7q(B







If you were to get the innerHTML of #source and insert it into #destination, 
the effective language changes from Chinese and Japanese and the three 
characters transform their shapes because browsers will use different fallback 
fonts.

- R. Niwa

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

[Ryosuke Niwa]

On Jun 28, 2013, at 5:32 PM, Zirak A  wrote:

> But that's a bit looking at it backwards. Selectors are supposed to be an
> abstraction over these methods, not the other way around.

No.

> The point here is that document fragments are documents - so they should have 
> a consistent API.

No.

> Adding this isn't about "backwards compatibility" or anything of the sort. 
> It's
> adding methods that people already use, because as said, not everyone uses
> selectors (and not just because of browser-compat).

getElementById is okay but we want to discourage authors from using methods 
like getElementsByTagName and getElementsByClassName that return live NodeList 
objects. They incur a lot of implementation cost in WebKit and hurts the DOM 
performance. e.g. whenever there is a LiveNode list somewhere in a document, 
WebKit walks up all ancestors of an inserted or removed element to clear their 
live node lists' caches.

On Jun 29, 2013, at 3:47 PM, Glenn Maynard  wrote:

> On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater  wrote:
> 
>> But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a
>> particular row, by id, in order to modify the contents of cells in that
>> row. I find it perverse to be using a style-related API call to do that.
>> 
> 
> CSS uses selectors, not the other way around.  querySelector() has nothing
> to do with styles.

Indeed.  Note that querySelector implementations in WebKit and Blink optimize 
#foo, .foo, etc... so that they're equally if not faster than getElementsById, 
getElementsByClassName, etc...

- R. Niwa

Re: [whatwg] Mutation Observer arguments format

[Ryosuke Niwa]

On Mar 14, 2013, at 12:49 PM, Alex Russell  wrote:

> The old API is confusing. We can do better, so we should.

I actually find the proposed syntax more confusing than the old syntax.

For starters, I don't want to remember which options were types and which are 
not since a mutation observer that observes attributes but doesn't observe 
attribute old data is a different "type" of a mutation observer than the one 
that does observe old data.

So while I understand some people may find the new syntax more appealing and 
easy to understand, I don't think it's a significant improvement over the old 
syntax that justifies the cost of changing the syntax at this point especially 
because it appears to be backward incompatible.

I think most of us are open to new syntax if it's significantly better than the 
current syntax and is backward compatible.

- R. Niwa

Re: [whatwg] Mutation Observer arguments format

[Ryosuke Niwa]

On Mar 12, 2013, at 10:31 AM, Anne van Kesteren  wrote:

> On Tue, Mar 12, 2013 at 5:02 PM, Brian Kardell  wrote:
>> Does it make sense?  Do you feel like I am hand-waving away any of your
>> concerns?  I hope not because the idea there is precisely to help address
>> concerns like these (as well as many others).
> 
> It makes sense and is doable, but given finite resources it's on
> balance with everything else we work on. E.g. the effort I put into
> drafting a new API and figure out the details will take away time from
> improving Fetch and XMLHttpRequest. The effort Adam will put into
> implementing the change and making sure it's tested will take away
> time from him working on HTML templates. Etc.
> 
> And that's not counting that we then have two ways of doing the same
> thing. That we need to update documentation. That it's not backwards
> compatible.

I agree with Anne and others that the proposed API change is not worth the cost 
we have to pay at this point in time.

- R. Niwa

Re: [whatwg] inputmode feedback

[Ryosuke Niwa]

On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri  wrote:
> To conclude, Mozilla is interested in implementing this set of keywords:
> verbatim, text, name, prose and digit (or numeric).

Why is name not an input type?

How does one decide whether a given semantics should be introduced as a type or 
a mode?

On Feb 15, 2013, at 12:28 AM, Takayoshi Kochi (河内 隆仁)  wrote:

> Hello Mounir,
> 
> On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri  wrote:
> 
>> Regarding the three Japanese specific types, it is not clear if
>> inputmode is the best way to solve the use cases intended to be solved.
>> Actually, 'kana' and 'katakana' are trying to give a hint about the
>> script that has to be used which seems to be orthogonal with the other
>> types. We could allow inputmode to have a set of values but that would
>> make the behaviour way more complex so I wonder if we couldn't try to
>> solve that problem with another attribute like inputscript.
>> 
> "three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?
> 
> I agree that it is weird 'kana' and 'katakana' are listed as inputmode
> attribute, and 'inputscript' sounds more reasonable place where they should 
> be listed.

Given the text in the spec "[t]he inputmode content attribute is an enumerated 
attribute that specifies what kind of input mechanism would be most helpful for 
users entering content into the form control," it makes sense for input mode to 
include kana and katakana.

On the other hand, I'm surprised to find that these modes are very specific to 
Japanese.

- R. Niwa

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

[Ryosuke Niwa]

On Jan 29, 2013, at 12:41 PM, Elliott Sprehn  wrote:

> 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 "request" and then not send a request.
> >
> > You can't go down that line of thinking because it doesn't generalize.
> > For instance why would I instantiate a class named "node" without
> > putting it into the tree?
> 
> There are all kinds of reasons why you may do this. Hence, we support it.
> 
> Reasoning by use case definitely generalises -- it's how we design
> everything around here. :-)
> 
> 
> But reasoning by naming certainly doesn't. His comment was about creating a 
> class named request. 

Sorry, I think you misunderstood me. I didn't mean that literally.

- R. Niwa

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

[Ryosuke Niwa]

On Jan 29, 2013, at 10:26 AM, Elliott Sprehn  wrote:

> On Tue, Jan 29, 2013 at 10:38 AM, Jake Archibald 
> wrote:
> 
>> On 29 JanuaJake Archibald ry 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. Is there an explanation laid out somewhere?
>> 
>> Why doesn't it seem like a good idea? Is there a use-case for creating
>> a Notification/XMLHttpRequest/WebSocket/EventSource without performing
>> their action?
> 
> Yes, because decoupling allocating from action lets you preallocate objects
> to perform a task in advance of executing the task. It lets you structure
> your code without having to worry about when something executes, and it
> lets you inspect the object in the web inspector without having the verb
> execute first.
> 
> For example you can do var request = new XMLHttp(  ) at the start of a
> function, but then later decide you didn't want to send the request, and
> never call send().

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

> It also lets you create clean abstractions and layers so
> one library may create the notification, but another one may eventually
> show it.

This seems like a valid concern. Do existing libraries do this with XHR and 
other objects that separate primary actions from instantiations?

- R. Niwa

Re: [whatwg] [selectors4] drag-and-drop pseudo-classes

[Ryosuke Niwa]

On Tue, Aug 14, 2012 at 12:53 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 14, 2012 at 12:13 PM, Ryosuke Niwa  wrote:
> > I'm asking how we're supposed to implement this pseudo-classes given that
> > the only way to know whether an element can receive the item is by firing
> > dragenter and/or dragover events. e.g.
>
> No, we can know it declaratively via the dropzone attribute.  That's
> what these will key off of in HTML.  In @dropzone, you can declare the
> types of data that it will accept, and you know the type of the data
> as soon as the drag starts, so you have all the info you need.
>

Okay, thanks for the clarification.

We obviously can't address "dropzones" that are only detectable during
> the dragover event.  That's fine - they just won't respond to these
> pseudo-classes.  Consider it an inducement to use the new, better
> model that @dropzone allows.
>

I'm not sure if I'm a big fun of that idea given that I haven't seen people
using dropzone attribute in wild. Have other browser vendors even
implemented it yet? (We haven't prefixed it in WebKit) All in all, I feel
like it's premature to build more features on top of it.

- Ryosuke

Re: [whatwg] [selectors4] drag-and-drop pseudo-classes

[Ryosuke Niwa]

On Tue, Aug 14, 2012 at 11:04 AM, Tab Atkins Jr. wrote:

> On Mon, Aug 13, 2012 at 11:55 PM, Ryosuke Niwa  wrote:
> > On Mon, Aug 13, 2012 at 9:19 PM, fantasai  >wrote:
> >> The CSSWG discussed drag-and-drop pseudo-classes today. The current
> >> proposal is to have three pseudo-classes:
> >>
> >>   * One for the element representing the drop target that
> >> would receive the item if it were dropped.
> >>   * One for all elements representing possible drop targets
> >> that could receive the item.
> >
> > How do we find these elements? On one hand, if we're only supporting
> > dropzone attribute, then adding new pseudo element seems unnecessary. On
> > the other hand, I can't think of ways to detect whether an element could
> > return false or prevents the default action on dragover/dragenter events
> > without firing those events.
>
> Just using [dropzone], yes.
>
> We're not adding a pseudo-element, we're adding pseudo-classes.
>
> I'm not sure how we can possibly do these without pseudo-classes.  Can
> you outline what you think it would be?


I'm asking how we're supposed to implement this pseudo-classes given that
the only way to know whether an element can receive the item is by firing
dragenter and/or dragover events. e.g.

http://dev.w3.org/csswg/selectors4/#drag-pseudos says
The :valid-drop-target pseudo-class represents an element that is a
possible drop target for an item that is currently being dragged in a
drag-and-drop interface.

How are we going to figure out whether a given element is a possible drop
target for an item, when the element can dynamically decide whether to
accept the item or not in dragenter/dragover events?

As well, the pseudo that matches "the drop target that will be used if
> you dropped right now" might not be expressible in pure CSS even given
> the above.  It's probably equivalent to "when you :hover it", but
> there are applications that basically have this functionality that
> work differently - for example, I think that the built-in Windows
> solitaire game highlight the closest drop target to the current mouse
> pointer, even if you're nowhere near the actual drop zone.
>

Yeah, and that's not compatible with how drag and drop are implemented on
the Web.

- Ryosuke

Re: [whatwg] [selectors4] drag-and-drop pseudo-classes

[Ryosuke Niwa]

On Mon, Aug 13, 2012 at 9:19 PM, fantasai wrote:

> The CSSWG discussed drag-and-drop pseudo-classes today. The current
> proposal is to have three pseudo-classes:
>
>   * One for the element representing the drop target that
> would receive the item if it were dropped.
>   * One for all elements representing possible drop targets
> that could receive the item.
>

How do we find these elements? On one hand, if we're only supporting
dropzone attribute, then adding new pseudo element seems unnecessary. On
the other hand, I can't think of ways to detect whether an element could
return false or prevents the default action on dragover/dragenter events
without firing those events.

- Ryosuke

Re: [whatwg] UndoManager: rationale for having undoManager.position and undoManager.item?

[Ryosuke Niwa]

On Mon, Jun 25, 2012 at 3:23 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@openbossa.org> wrote:

> Hi,
>
> In the June 8, 2012 version, there's a note after the description of
> undoManager.item:
>
> "Note: Being able to access an arbitrary element in the undo
> transaction history is needed to allow scripts to determine whether
> new DOM transaction and the last DOM transaction should being to the
> same entry or not."
>
> I'm guessing undoManager.position exists to be used together with
> undoManager.item to achieve this.
>
> After checking the problem descriptions again
> (http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions), I'm
> wondering if the use case is only checking the last transaction,
> couldn't we have a smaller API? Or we have other situations where
> "peeking" in the undo stack is desired? Maybe is needed for a specific
> case in Collaborative editing that I couldn't grasp in the problem
> description?
>

There was a use case for collaborative editing case where developers wanted
to be able to modify undo stack as the remote data model changes but I
suppose they could achieve the same effect by removing all entries in the
undo manager & adding new entries?

- Ryosuke

Re: [whatwg] Security restriction allows content thievery

[Ryosuke Niwa]

On Sun, Jul 15, 2012 at 4:02 PM, Robert Eisele  wrote:

> 2012/7/16 Tab Atkins Jr. 
> > On Sun, Jul 15, 2012 at 3:22 PM, Robert Eisele  wrote:
> > > Browsers are very restrictive when one tries to access the contents of
> > > different domains (including the scheme), embedded via framesets. This
> is
> > > normally a good practice, but I'd suggest to weaken this restriction
> for
> > > the data: URI schema.
> > >
> > > I'm currently building an analysis system like Google Analytics, which
> > gets
> > > embedded into a website via a small JavaScript snippet. When I analyzed
> > the
> > > data, I came across a very interesting trick because I got a lot of
> > > requests (with the data from location.href) where the entire website
> was
> > > embedded into a data:text/html URI - except that all ads of the page
> were
> > > replaced. Fortunately, my tracking code has been left without
> > > modifications.
> > >
> > > But the scary thing is that this way you can monetize foreign content
> by
> > > simply embedding it somewhere you can direct traffic to. That's pretty
> > > clever, because the original site owner doesn't notice this abuse due
> to
> > > the fact that top.location.href isn't readable. Or even worse, he would
> > > never notice it at all when he doesn't sniff the URI with JavaScript,
> > > because image files would have no referrer.
> > >
> > > My final approach to convict the abuser is based on the fact, that the
> > > JavaScript was dynamically loaded from my server and that I can write
> to
> > > location.href. So I added this piece of code:
> > >
> > > if (top.location.protocol === 'data:') {
> > > top.location.href = 'http://example.com/trap/';
> > > }
> > >
> > > But even then the referrer will not be passed to the server. So my
> > proposal
> > > is that the data URI schema gets an exception on this security
> behavior.
> >
> > The problem you outline is not directly tied to the solution you
> > present.  You can scrape a site and display it as your own without any
> > fancy tricks, just by downloading all the resources and hosting them
> > yourself.  This merely consumes a little more bandwidth for the
> > attacker, since they're hosting the images/etc themselves.
> >
>
> But you would get a valid referrer if the tracking code wasn't removed. The
> data: protects the abuser in an unecessary way. But you're absolutely right
> that the solution I present isn't entirly tied to the problem.
>

The embedder can easily remove the tracking code. Better yet, the embedder
can host the content on his server and disallow access to all external
resources to cripple your tracking code.

> The correct solution to this kind of problem is legal - this is simple
> > copyright violation.
>
> But if you don't have a chance to get information about the attacker, you
> can't sue him. I had the strange idea to use a prompt to ask the user for
> the original URL in his address bar. But as I said, that's strange.
>

That sounds like a problem we can't solve.

- Ryosuke

Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?

[Ryosuke Niwa]

On Fri, Jul 13, 2012 at 3:17 PM, Ian Hickson  wrote:

> On Fri, 13 Jul 2012, Ryosuke Niwa wrote:
> >
> > According to
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection
> >
> > *HTMLCollection* returns the first element.
>
> This is for compat in the default case, I believe.
>
>
> > *HTMLAllCollection* returns the first element or another
> HTMLAllCollection
> > if there are multiple elements
>
> This is needed for IE compat.
>

We can't use live NodeList or a regular HTMLCollection?

> *HTMLFormControlsCollection* returns the first element or RadioNodeList if
> > there are multiple elements
>
> This is needed to support the radio button value feature.
>
>
> > *HTMLOptionsCollection* returns the first element or live NodeList if
> there
> > are multiple elements
>
> This is for compat, I believe. (We don't want to return just a node if
> there are many matching.)
>

We can't return HTMLAllCollection or RadioNodeList here?

 > Can those 3 classes somehow return the same object? FWIW, WebKit has
> > always returned a static node list.
>
> WebKit doesn't support the microdata and radio button features,
> presumably, and is presumably less than perfectly compatible with the Web
> for the others. :-)
>

I'm not certain if we're willing to change our behavior to match the spec.
We haven't gotten any bug reports due to this behavior as far as I know,
and following the spec introduces a significant code complexity.

- Ryosuke

[whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?

[Ryosuke Niwa]

According to
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection

*HTMLCollection* returns the first element.
*HTMLAllCollection* returns the first element or another HTMLAllCollection
if there are multiple elements
*HTMLFormControlsCollection* returns the first element or RadioNodeList if
there are multiple elements
*HTMLOptionsCollection* returns the first element or live NodeList if there
are multiple elements
*HTMLPropertiesCollection* returns PropertyNodeList

In particular, I'm puzzled that
HTMLAllCollection, HTMLFormControlsCollection, and HTMLOptionsCollection
all return different objects. Why?

Can those 3 classes somehow return the same object? FWIW, WebKit has always
returned a static node list.

Best,
Ryosuke Niwa
Software Engineer
Google Inc.

Re: [whatwg] Undo Manager specs is confusing in the contenteditable section

[Ryosuke Niwa]

On Wed, Jun 20, 2012 at 12:21 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@openbossa.org> wrote:
>
>  > *2.2.1 Undo scope and contenteditable*
> > *
> > *When the contenteditable content attribute is added to an element, the
> > user agent must remove all entries in the undo transaction histories
> > of the editable
> > undo scope hosts that are descendent of the element and have become
> > editable without unapplying or reapplying the entries and disconnect the
> > corresponding UndoManagers as if the undoscope content attribute was
> > removed from all descendent nodes excluding undo scope hosts and their
> > descendents.*
> >
> > What does "editable undo hosts" imply here?
>
> From my understanding they are the elements that were undo hosts but
> now, because the addition of contenteditable content attribute, became
> editable elements, so not undo hosts anymore.
>

I agree the wording here was confusing. Revised it to clarify:
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html#undo-scope-and-contenteditable

> Also when contenteditable is added to an element all
> > the descendant elements become editable, so none of the descendants
> should
> > be a undo scope host as "undoscope content attribute on an editable
> element
> > is ignored". So is "*excluding undo scope hosts and their descendents*"
> > valid?
>
> We can have non-editable elements that are descendents of an element
> with contenteditable=true. For example:
>
> 
>   This will be editable
>   This will remain not
> editable
> 
>
> When div "container" gets contenteditable=true, the div "A" will have
> its undoManager disconnected, but not the div "B", because its not
> editable. Would a non-normative box with an example like this one be
> helpful in the spec?
>

Thanks for the example! Added it to 2.2.1.

Maybe we could change the second paragraph of 2.2.1 to make things clearer:
>
> 8<---
> When the contenteditable content attribute is added to an element, the
> user agent must remove all entries in the undo transaction histories
> of the descendents of the element that were undo scope hosts but have
> become editable without unapplying or reapplying the entries and
> disconnect the corresponding UndoManagers as if the undoscope content
> attribute was removed from the now editable descendent nodes.
> --->8---
>

I think the first part about removing entires is redundant since
disconnected undo manger will throw errors on all attempts to modify the
UndoManager. If anything, we can remove all entries in the definition of
"disconnect" instead of the section 2.2.1

- Ryosuke

Re: [whatwg] Two small typos in UndoManager spec

[Ryosuke Niwa]

Fixed. Thanks for the report.

On Wed, Jun 20, 2012 at 3:58 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@openbossa.org> wrote:

> Hi,
>
> Found in 8/June/2012 version.
>
> Section 3.2: the first example box says "In the following example,
> execute and undo attributes are modified:" but executeAutomatic and
> undo are modified in the actual example.
>
> Section 3.4: "user agnets" should be "user agents", it appear three times.
>
> --
> Caio Marcelo de Oliveira Filho
> openBossa @ INdT - Instituto Nokia de Tecnologia
>

Re: [whatwg] Exceptions in UndoManager

[Ryosuke Niwa]

On Wed, May 30, 2012 at 8:43 AM, Alex Vincent  wrote:

>
>1. "What state will the UndoManager be in when an exception happens?"
>There may be transactions that were undone, cropped off by the transact()
>call, which per the spec are now unrecoverable.  Also, in the undo or redo
>cases, we might be in the middle of a merged transaction.  The spec says we
>can't call undo while we're unapplying a transaction... nor can we call
>redo.  So where will we be - both during the event dispatch and in the
>aftermath?
>2. "What information about the exception will be included with the
>event - or with the UndoManager?"
>3. "If the UndoManager can recover somehow to a known good state
>without intervention, how can it indicate that - and possibly, what that
>good state would look like?"
>4. "If no recovery is completed, is it acceptable to mark the
>UndoManager in an error state and prevent further transactions from either
>happening or being recorded until both undo and redo stacks have been
>completely cleared?"  (I'm thinking of a fatal error state, which can be
>recovered if you throw away all your history.)
>5. If there is a recovery by one event listener, should another event
>indicating that recovery be dispatched, so that earlier event listeners are
>aware of the new good state?
>
> I can write up a simple HTML + SVG document illustrating the UndoManager
> Exception cases I can dream up, if anyone's interested.  There's four main
> areas: during transact with no undone transactions, during undo where we
> may be in the middle of a transaction group, during redo where we may be in
> the middle of a transaction group, and during transact where some
> transactions have been undone.
>
> For question 3, I would propose including an UndoManager mockup without
> methods:  a static data representation of the default after-state.  Note
> that it is perfectly okay in my opinion for the UndoManager to report "I
> cannot recover from this on my own," and not provide this mockup at all.
>
For point 1, we should move step 2 (clear all redo) in the definition of
transact() to after step 3.

Points 2 and 5 makes me think that we should just propagate the exception
instead of firing an event. Whoever is catching the exception can take
appropriate actions then.

I don't understand what you mean in point 3.

What's the use case for point 4.

In general, I don't want to make the spec too complicated. I want to
provide the simplest API that gets job done. If there are some use cases
that require elaborate exception handling, then I would like to let
scripts/libraries provide such an API instead of baking it natively into
the spec. Of course, the native UndoManager should be flexible enough to
accommodate such needs.

- Ryosuke

Re: [whatwg] Random comments about UndoManager

[Ryosuke Niwa]

On Tue, May 29, 2012 at 11:27 PM, Ryosuke Niwa  wrote:

> I'm sorry for the delay. I've updated the spec per your comment:
> http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html
>
> On Thu, Apr 12, 2012 at 10:27 AM, Ryosuke Niwa  wrote:
>
>> On Thu, Apr 12, 2012 at 9:19 AM, Olli Pettay wrote:
>>>
>>> Should it be defined that  and  have implicit undoscope
>>> by default?
>>
>>
>> The problem is that we don't have a way of removing undo scope. We might
>> need to allow undoscope=false/true.
>>
>
> I still haven't figured out this problem. On one hand, this default
> behavior makes sense but we probably need a way to share undo manager
> between multiple text fields. But making undoscope content attribute take a
> boolean just to deal with this case is inelegant at best.
>

I talked about this about with Ojan and in person and he came up with
undoscope=shared to indicate that the undo manager of the text field should
be shared.  Alternatively, we can have explicit "undoscope=false" to mean
the undo scope is not set, thereby sharing with its parent element.

I haven't heard anything from Microsoft yet but it appears that WebKit can
change its behavior to have one undo manager per text field as far as I've
consulted with various WebKit contributors. If anything, we can leave the
default implementation dependent and let scripts figure it out by
inspecting the undoScope attribute on input/textarea elements.

- Ryosuke

Re: [whatwg] Proposed addition to Drag and Drop API

[Ryosuke Niwa]

On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain  wrote:

> I would prefer not to visually drag the entire post around (which is what
> happens if I set draggable to true on the post container). My goal is to
> set draggable on a container element and only show a small element when the
> user starts dragging.
>

Ah, that's an interesting use case. Thanks for clarification. Do you have a
concrete proposal for this? (e.g. adding new content attribute / element).

- Ryosuke

Re: [whatwg] Proposed addition to Drag and Drop API

[Ryosuke Niwa]

On Fri, Jun 29, 2012 at 4:12 PM, Alex Bain  wrote:

> I've spent the past few days working with the Drag and Drop API and I'd
> like to propose an addition to the spec to aid developers and designers in
> creating accessible drag interfaces.
>
> **Use case:**
>
> I'm developing an app that allows users to drag pieces of user generated
> content (Posts) from one part of the app to another. A Post is represented
> as a DOM subtree with multiple components - a title, some images, text, and
> so forth. I wanted to create an interaction where the user could click and
> drag anywhere on the Post (large click target for accessibility purposes),
> see a subset of the Post as a drag indicator (the title, for example), and
> then be able to drop that elsewhere in the app.
>

You can't use draggable content attribute?
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-draggable-attribute

- Ryosuke

[whatwg] Exceptions in UndoManager

[Ryosuke Niwa]

When an exception is thrown within transact(), the most sane behavior
appears to be rolling back all DOM changes that have made thus far (this in
turn may also fail due to mutation events, etc...). Also this is not
possible with manual transactions because browsers don't keep track of
what's happening in the DOM, etc...

So how about just firing an event like DOMTransactionException at the undo
scope host to let scripts handle them?

- Ryosuke

On Sat, May 26, 2012 at 8:01 PM, Alex Vincent  wrote:
>
> * The spec is inconsistent in a few places.  For instance, in the green
> non-normative section, clearUndo states:
> Removes entries in the undo transaction
> history >before
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>and
> resets
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>to
> 0.
>
> However, in the normative part, it states:
> The clearUndo() method must remove all entries in the undo transaction
> history <
> http://rniwa.com/editing/undomanager.html#undo-transaction-history>after
> the undo
> position .
>
> Note that one of these states "before", and the other states "after".  This
> contradiction is not implementable.
>
> * The spec mentions a "DOM transaction
> group",
> but does not define that.
>
> * When adding a transaction to a DOMTransaction[] as part of execute's
> merge being true, do we add it to the beginning or the end of the list?
> This matters for .item().
>
> * Exception handling is woefully undefined in this spec:
> ** If my transaction throws an exception during UndoManager.execute(), how
> should that be handled? What happens to transaction groups that were
> previously undone?
> ** If my transaction throws an exception during .undo(), how should that be
> handled?
> ** Ditto redo.
>
> * What precisely lives at UndoManager.item(0)?  The most recently completed
> transaction, or the oldest?
>
> * When UndoManager.execute() is called with an object not implementing
> .undo, or .redo, should we fire some kind of warning to the user?  What
> should happen when we try to undo that transaction?
>
> Given all the above, I think I need to write some tests for UndoManager.
> Anyone mind Jasmine-based tests?
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>

Re: [whatwg] UndoManager questions

[Ryosuke Niwa]

Done: http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html

- Ryosuke

On Tue, May 29, 2012 at 9:17 PM, Ryosuke Niwa  wrote:

> On Sat, May 26, 2012 at 8:01 PM, Alex Vincent  wrote:
>
>> For those not familiar, the spec lives here:
>> http://rniwa.com/editing/undomanager.html
>
>
> It has been moved to
> http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html
>
>
>> * The spec is inconsistent in a few places.  For instance, in the green
>> non-normative section, clearUndo states:
>> Removes entries in the undo transaction
>> history<
>> http://rniwa.com/editing/undomanager.html#undo-transaction-history>before
>> position<
>> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>and
>> resets
>> position<
>> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>to
>> 0.
>>
>
> This statement in the non-formative section is correct.
>
> However, in the normative part, it states:
>> The clearUndo() method must remove all entries in the undo transaction
>> history <
>> http://rniwa.com/editing/undomanager.html#undo-transaction-history>after
>> the undo
>> position <http://rniwa.com/editing/undomanager.html#undo-position>.
>>
>
> This statement is incorrect. Will fix.
>
> * The spec mentions a "DOM transaction
>> group<http://rniwa.com/editing/undomanager.html#dom-transaction-group>",
>> but does not define that.
>>
>
> Will fix.
>
> * When adding a transaction to a DOMTransaction[] as part of execute's
>> merge being true, do we add it to the beginning or the end of the
>> list? This matters for .item().
>
>
> I meant at the end, but now that I realize this is inconsistent with the
> way entries in the undoManager is ordered. Will change so that it'll be
> added at the beginning instead.
>
> * Exception handling is woefully undefined in this spec:
>> ** If my transaction throws an exception during UndoManager.execute(), how
>> should that be handled? What happens to transaction groups that were
>> previously undone?
>> ** If my transaction throws an exception during .undo(), how should that
>> be
>> handled?
>> ** Ditto redo.
>>
>
> Let's start a new thread about this.
>
> * What precisely lives at UndoManager.item(0)?  The most recently completed
>> transaction, or the oldest?
>>
>
> The most recent.
>
> * When UndoManager.execute() is called with an object not implementing
>> .undo, or .redo, should we fire some kind of warning to the user?  What
>> should happen when we try to undo that transaction?
>>
>
> There are valid use cases for creating transactions without undo or redo
> method (e.g. need to do something only in undo such as updating toolbar).
>
> - Ryosuke
>

Re: [whatwg] Random comments about UndoManager

[Ryosuke Niwa]

I'm sorry for the delay. I've updated the spec per your comment:
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html

On Thu, Apr 12, 2012 at 10:27 AM, Ryosuke Niwa  wrote:

> On Thu, Apr 12, 2012 at 9:19 AM, Olli Pettay wrote:
>>
>> Should it be defined that  and  have implicit undoscope
>> by default?
>
>
> The problem is that we don't have a way of removing undo scope. We might
> need to allow undoscope=false/true.
>

I still haven't figured out this problem. On one hand, this default
behavior makes sense but we probably need a way to share undo manager
between multiple text fields. But making undoscope content attribute take a
boolean just to deal with this case is inelegant at best.

What does "destroy the corresponding UndoManager for the scope." mean?
>> If JS keeps a pointer to the manager, the object sure stays alive, and
>> if I read the draft correctly, one can use some of the methods of
>> a destroyed UndoManager.
>>
>
> Yeah, I need to define it properly. It basically means that element's
> undoManager property will return null thereafter.
>

I've introduced new concept of an undo manager being "disconnected" in
which state undo manager is immutable.

I should define what happens when you call methods on those orphaned
> methods I guess.
>

Throws INVALID_ACCESS_ERR.

- Ryosuke

Re: [whatwg] UndoManager questions

[Ryosuke Niwa]

On Sat, May 26, 2012 at 8:01 PM, Alex Vincent  wrote:

> For those not familiar, the spec lives here:
> http://rniwa.com/editing/undomanager.html


It has been moved to
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html


> * The spec is inconsistent in a few places.  For instance, in the green
> non-normative section, clearUndo states:
> Removes entries in the undo transaction
> history >before
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>and
> resets
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>to
> 0.
>

This statement in the non-formative section is correct.

However, in the normative part, it states:
> The clearUndo() method must remove all entries in the undo transaction
> history <
> http://rniwa.com/editing/undomanager.html#undo-transaction-history>after
> the undo
> position .
>

This statement is incorrect. Will fix.

* The spec mentions a "DOM transaction
> group",
> but does not define that.
>

Will fix.

* When adding a transaction to a DOMTransaction[] as part of execute's
> merge being true, do we add it to the beginning or the end of the
> list? This matters for .item().


I meant at the end, but now that I realize this is inconsistent with the
way entries in the undoManager is ordered. Will change so that it'll be
added at the beginning instead.

* Exception handling is woefully undefined in this spec:
> ** If my transaction throws an exception during UndoManager.execute(), how
> should that be handled? What happens to transaction groups that were
> previously undone?
> ** If my transaction throws an exception during .undo(), how should that be
> handled?
> ** Ditto redo.
>

Let's start a new thread about this.

* What precisely lives at UndoManager.item(0)?  The most recently completed
> transaction, or the oldest?
>

The most recent.

* When UndoManager.execute() is called with an object not implementing
> .undo, or .redo, should we fire some kind of warning to the user?  What
> should happen when we try to undo that transaction?
>

There are valid use cases for creating transactions without undo or redo
method (e.g. need to do something only in undo such as updating toolbar).

- Ryosuke

Re: [whatwg] Proposal in supporting the writing of "Arabizi"

[Ryosuke Niwa]

On Thu, May 10, 2012 at 1:28 PM, Sami Eljabali  wrote:

> Because then they wouldn't be HMTL5 compliant vs not having a nifty
> feature. How would you push this forward being adopted? I'm mostly likely
> not thinking creatively enough.
>

Why would it be a part of HTML5 if vendors don't want to implement it?

Just because something has been proposed to be added to HTML5 doesn't mean
it will be supported by all browsers. In fact, if some vendors strongly
oppose, then we're going to remove it from the spec.

What you need to do first is to convince Microsoft and Apple that this is a
valuable feature they want to have instead of trying to circumvent the
process. Quite frankly, I would be opposed to adding this feature to WebKit
/ Chromium as well although I can't speak for my employer or the boarder
WebKit or Chromium open source communities.

- Ryosuke

Re: [whatwg] Should editable elements have placeholder attribute?

[Ryosuke Niwa]

On Wed, May 2, 2012 at 10:49 AM, Ojan Vafai  wrote:

> textContent will strip a bunch of visible content (images, iframes,
> embeds, etc.).
>
> Another edge case to consider:
>  style="background-color:red;width:100px;height:100px">
>

Should that be considered as non-empty? If so, maybe we should define it as
either the content height or the content width being 0?

But what about  ? Should this also be considered as
non-empty?

- Ryosuke

Re: [whatwg] Should editable elements have placeholder attribute?

[Ryosuke Niwa]

On Wed, May 2, 2012 at 10:15 AM, Charles Pritchard  wrote:

> On 5/2/12 10:08 AM, Ryosuke Niwa wrote:
>
>> On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai  wrote:
>>
>>  I'm OK with having when the placeholder is displayed be up to the UA. I
>>> can see that being platform specific.
>>>
>>> But, we should spec when content is eligible for showing a placeholder
>>> (i.e. we should define what "looks empty" means). I don't see any benefit
>>> in browsers behaving differently here. This part is not
>>> platform-specific.
>>> It's just hard to figure out how to spec it.
>>>
>>>  Maybe when element.innerText or element.textContent is empty?
>>
>
> Is this something we might have a CSS selector for in the future?
>

Sounds reasonable. We already have empty pseudo element but that won't
apply to div with just .

So we'd have a css selector of something like:
>
> ul[text()=""] { content: attr(placeholder); }
>

Such a CSS selector will be very expensive to implement. I don't think we
want something that generic. I think just adding a pseudo element that
matches a visibly empty element will be fine.

- Ryosuke