Re: [whatwg] Proposal: navigator.cores

[Rik Cabanier]

On Wed, Jul 2, 2014 at 2:19 AM, Ryosuke Niwa  wrote:

> 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.
>

Since there are now 2 implementations, it should be added to the spec
instead of just being a wiki.

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

[Boris Zbarsky]

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.


-Boris

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] Proposal: navigator.cores

[Nils Dagsson Moskopp]

Eli Grey  writes:

> We want to claim 6 in that situation. If the API claimed less than 6
> on Samsung's Exynos 5 Hexa (2x A15 cores + 4x A7 cores), then the
> cores will be underutilized.

Implying it is right for any application to utilize all cores available
in a multi-process environment that may or may not exist within a mobile
(power-limited) device? Again, this reminds me of the „How can I find
out how much RAM I can maximally allocate“ questions.

-- 
Nils Dagsson Moskopp // erlehmann