[whatwg] Closing the WHATWG mailing lists

[Philip Jägenstedt]

Hi all,

This list has not been very active in recent years and maintaining the
mailing list setup as our hosting infrastructure change has become a
bit of a burden. Because of this, I'm proposing that this and the
other (even less active) lists are closed in favor of GitHub issues.
If you have concerns about this, please reply here or on this tracking
issue: https://github.com/whatwg/meta/issues/153

Details follow.

wha...@whatwg.org as well as the "help" and "implementors" lists will
be configured to auto-reply with an explanation, pointing to
https://whatwg.org/mailing-list which is being updated in
https://github.com/whatwg/whatwg.org/pull/269.

lists.whatwg.org will also be redirected to
https://whatwg.org/mailing-list with an effort made to help find the
original link on web.archive.org.

Philip

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] [blink-dev] Intent to Ship: Scroll To Text Fragment

[Chris Wilson]

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.

"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] [blink-dev] Intent to Ship: Scroll To Text Fragment

[Yoav Weiss]

On Fri, Oct 25, 2019 at 4:04 AM 'Maciej Stachowiak' via blink-dev <
blink-...@chromium.org> wrote:

>
>
> > On Oct 24, 2019, at 1:49 PM, fantasai 
> wrote:
> >
> > On 10/9/19 8:10 PM, Nick Burris wrote:
> >> Summary
> >> Scroll To Text allows URLs to link to a piece of text in a webpage
> rather than just linking to an existing element fragment. The motivating
> use cases are to enable user sharing of specific content and allow
> deep-linking references to information.
> >
> > So, like, this sounds conceptually like a great feature to have for the
> Web.
> > But this
> >
> >> Edge: No signals
> >> Firefox: No signals <
> https://github.com/mozilla/standards-positions/issues/194>
> >> Safari: No signals
> >
> > makes it seem like you really haven't put much effort into figuring out
> where the other browser vendors stand on the issue. Given this is an Intent
> to Ship, I interpret not having figured out where the other vendors stand
> even at the coarse level of “excited to have spec, plan to implement”,
> “supportive but not prioritizing; will accept patches”, or “opposed to the
> feature in its current state” as not really caring what they think. You
> have contacts into these organizations; I am sure you could solicit such
> answers where there aren't any if you thought it was necessary.
> >
> > Google engineers keep asserting that, no, we really care about
> standardization and moving the Web forward together with the other browser
> vendors. Look at the processes we made to help us do that! But Web
> standardization efforts have always tried to move forward on the basis of
> consensus. Meanwhile the attitude here seems to be ”There was a template
> for the positions of other browsers, a blank answer could be provided in
> the template, nobody reviewing it cares that there was a blank answer, so
> let's just ship the thing we (Google) want.”
> >
> > If this was a blank code review in your template, I imagine you would
> try harder to get the reviewer's answer, and give a good explanation of
> your attempts and their failure if indeed you could not solicit a response,
> before asking for lgtm.
>
> I don’t think anyone at Apple was asked to provide a position. It’s true
> this spec has been out there for a while, but there’s so many specs these
> days that it’s hard to predict which will be up for an Intent to Ship next.
>
> I often see links to an Intent to Ship or Intent to Implement where Safari
> is noted as “no public signals” or “no signals” but no one actually asked
> us. Sometimes I even see this stated when we clearly said somewhere
> (perhaps in an issue comment) that we think the feature is a bad idea, at
> least as proposed.
>
> 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.
>

What would be the best way to solicit such feedback in a scalable way? No
all engineers sending intents personally know someone on the WebKit team to
ask for their opinion.
Would opening an issue on WebKit's bugzilla be the right way to get such an
opinion?


>
> 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.
>
> (This is not an opinion on the specific spec; it seems like a generally
> good feature, but the fragment directive syntax and requirement for UAs to
> strip it seems bound to cause interop problems with browsers that don’t
> implement this spec.)
>
>
> >
> > Yoav Weiss wrote:
> >
> >> When it comes to venue, the current spec's processing seems to be
> mostly monkey-patching the HTML and URL specs, indicating that WHATWG is
> probably the right venue for this to graduate to. At the same time, landing
> features in WHATWG specs require multi-engine commitment, and looking at
> Mozilla's 2.5-months-old standards position issue doesn't really indicate
> implementer commitment, or anything at all. From a practical standpoint,
> it's clearer and easier for the spec to live as a standalone document
> rather than a WHATWG PR, while we're waiting for multi-engine commitment.
> >> But, that in no means preclude collaboration. The spec is in WICG,
> which was built specifically to enable multi-vendor collaboration when
> incubati

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

[Anne van Kesteren]

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

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

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

[Yoav Weiss]

On Thu, Oct 24, 2019 at 10:49 PM fantasai 
wrote:

> On 10/9/19 8:10 PM, Nick Burris wrote:
> >
> > Summary
> >
> > Scroll To Text allows URLs to link to a piece of text in a webpage
> rather than
> > just linking to an existing element fragment. The motivating use cases
> are to
> > enable user sharing of specific content and allow deep-linking
> references to
> > information.
>
> So, like, this sounds conceptually like a great feature to have for the
> Web.
> But this
>
> > Edge: No signals
> >
> > Firefox: No signals <
> https://github.com/mozilla/standards-positions/issues/194>
> >
> > Safari: No signals
>
> makes it seem like you really haven't put much effort into figuring out
> where
> the other browser vendors stand on the issue. Given this is an Intent to
> Ship,
> I interpret not having figured out where the other vendors stand even at
> the
> coarse level of “excited to have spec, plan to implement”, “supportive but
> not
> prioritizing; will accept patches”, or “opposed to the feature in its
> current
> state” as not really caring what they think. You have contacts into these
> organizations; I am sure you could solicit such answers where there aren't
> any
> if you thought it was necessary.


> Google engineers keep asserting that, no, we really care about
> standardization
> and moving the Web forward together with the other browser vendors. Look
> at
> the processes we made to help us do that! But Web standardization efforts
> have
> always tried to move forward on the basis of consensus. Meanwhile the
> attitude
> here seems to be ”There was a template for the positions of other
> browsers, a
> blank answer could be provided in the template, nobody reviewing it cares
> that
> there was a blank answer, so let's just ship the thing we (Google) want.”
>
> If this was a blank code review in your template, I imagine you would try
> harder to get the reviewer's answer, and give a good explanation of your
> attempts and their failure if indeed you could not solicit a response,
> before
> asking for lgtm.
>

If you look at the linked TAG review issue
<https://github.com/w3ctag/design-reviews/issues/392>, you could see that
we have solicited and got opinions from various engineers working for said
browser vendors. (and addressed multiple concerns raised)
However, at least when it comes to Mozilla, my understanding is that
opinions of their engineers don't count for the purpose of stating
support, *unless
expressed on their standards positions repo alongside an official
commitment*.
An issue <https://github.com/mozilla/standards-positions/issues/194> was
opened on that repo almost three months ago, trying to solicit their
opinions and commitment. We have received zero replies on that issue.
If you have any suggestions as to what we could have better done on that
front, we'd definitely take them into consideration for next time.


>
> Yoav Weiss wrote:
>
> > When it comes to venue, the current spec's processing seems to be mostly
> > monkey-patching the HTML and URL specs, indicating that WHATWG is
> probably
> > the right venue for this to graduate to. At the same time, landing
> features
> > in WHATWG specs require multi-engine commitment, and looking at
> Mozilla's
> > 2.5-months-old standards position issue doesn't really indicate
> implementer
> > commitment, or anything at all. From a practical standpoint, it's
> clearer
> > and easier for the spec to live as a standalone document rather than a
> > WHATWG PR, while we're waiting for multi-engine commitment.
> >
> > But, that in no means preclude collaboration. The spec is in WICG, which
> > was built specifically to enable multi-vendor collaboration when
> incubating
> > new ideas. I'm sure everyone would be thrilled to have your feedback
> directly
> > there, to make sure we get this right.
>
> I would like to point out a couple things:
>
> 1. WICG is explicitly billing itself an incubation venue, not a
> standardization venue. At the point you're planning to ship a feature, I
> think
> that qualifies as beyond incubation, yes? So continuing work there at this
> point would be inappropriate.
>

The WICG is indeed not a standardization venue, and once we have support
from other vendors, we should definitely move the specification to one. But
as can be noted reading through the Blink interoperability principles
document
<https://docs.google.com/document/d/1romO1kHzpcwTwPsCzrkNWlh0bBXBwHfUsCt98-CNzkY/edit#heading=h.t71a2ioil8j0>,
"being on a standards track" is not a shipping requirement for a feature.
We aren't always going to wait until Mozilla and/or Apple are officially 

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

[fantasai]

On 10/9/19 8:10 PM, Nick Burris wrote:


Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than 
just linking to an existing element fragment. The motivating use cases are to 
enable user sharing of specific content and allow deep-linking references to 
information.


So, like, this sounds conceptually like a great feature to have for the Web.
But this


Edge: No signals

Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>

Safari: No signals


makes it seem like you really haven't put much effort into figuring out where 
the other browser vendors stand on the issue. Given this is an Intent to Ship, 
I interpret not having figured out where the other vendors stand even at the 
coarse level of “excited to have spec, plan to implement”, “supportive but not 
prioritizing; will accept patches”, or “opposed to the feature in its current 
state” as not really caring what they think. You have contacts into these 
organizations; I am sure you could solicit such answers where there aren't any 
if you thought it was necessary.


Google engineers keep asserting that, no, we really care about standardization 
and moving the Web forward together with the other browser vendors. Look at 
the processes we made to help us do that! But Web standardization efforts have 
always tried to move forward on the basis of consensus. Meanwhile the attitude 
here seems to be ”There was a template for the positions of other browsers, a 
blank answer could be provided in the template, nobody reviewing it cares that 
there was a blank answer, so let's just ship the thing we (Google) want.”


If this was a blank code review in your template, I imagine you would try 
harder to get the reviewer's answer, and give a good explanation of your 
attempts and their failure if indeed you could not solicit a response, before 
asking for lgtm.


Yoav Weiss wrote:

When it comes to venue, the current spec's processing seems to be mostly 
monkey-patching the HTML and URL specs, indicating that WHATWG is probably 
the right venue for this to graduate to. At the same time, landing features 
in WHATWG specs require multi-engine commitment, and looking at Mozilla's 
2.5-months-old standards position issue doesn't really indicate implementer 
commitment, or anything at all. From a practical standpoint, it's clearer 
and easier for the spec to live as a standalone document rather than a 
WHATWG PR, while we're waiting for multi-engine commitment.


But, that in no means preclude collaboration. The spec is in WICG, which 
was built specifically to enable multi-vendor collaboration when incubating 
new ideas. I'm sure everyone would be thrilled to have your feedback directly 
there, to make sure we get this right.


I would like to point out a couple things:

1. WICG is explicitly billing itself an incubation venue, not a 
standardization venue. At the point you're planning to ship a feature, I think 
that qualifies as beyond incubation, yes? So continuing work there at this 
point would be inappropriate.


2. If the WHATWG rules for incorporating something are too stringent to allow 
standardization in a timely manner, maybe you should consider changing them? 
It's not like Google has no say in the WHATWG process. Perhaps something like 
“two implementation commitments *or* implemented in one browser with other 
browsers at least in favor of the feature and willing to implement it at some 
point in the future even if they haven't committed to apply their own 
resources yet” could be enough for inclusion.


To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good work: 
if your process is inhibiting you from doing said work, you should fix said 
process. Allowing Google to do standardization work in an appropriate 
multi-vendor standards forum, and using that process to seek positive 
consensus on its proposals prior to deciding to ship, would be better than the 
circumvention of the standardization processes *and spirit* being demonstrated 
here, I would think.


~fantasai

[whatwg] [CSSWG][css-lists-3] Updated WD of CSS Lists Level 3

[fantasai]

The CSS WG has published an updated Working Draft of the CSS Lists Module Level 
3:
https://www.w3.org/TR/css-lists-3/

This module contains CSS features related to list markers and counters: 
styling them, positioning them, and manipulating their value.


This update contains a major clean-up of the “Automatic Numbering with 
Counters” section, including fixing various sync errors against CSS2.1. It 
should now be usable as a reference for implementation.


[See also announcement on the previous update, which was a rewrite of the 
list-styling section: 
https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html ]


Major areas of work left include:
  - Improving definitions for how list markers are positioned and
  how they impact layout. (This is largely undefined at the moment.)
  - Figuring out how to best support ol[reversed] list numbering for HTML.

i18n-related open issues include:
  - https://github.com/w3c/csswg-drafts/issues/4209 [syntax for marker-side]
  - https://github.com/w3c/csswg-drafts/issues/4202 ['direction' on markers]

a11y-related open issues include:
  - https://github.com/w3c/csswg-drafts/issues/4201

HTML-related open issues include:
  - https://github.com/w3c/csswg-drafts/issues/4181 reversed list decrement
  - https://github.com/w3c/csswg-drafts/issues/4211 reversed list start value

Please review the draft, and send any comments to , prefixed 
with [css-lists-3] (as I did on this message) or (preferably) file them in the 
GitHub repository at

  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

[whatwg] hi all!

[poet]

hi all!

new to the list and html, trying to learn. Anyone who wants to be in  
touch, contact me!  p...@poeticstreet.com


Regards! i read u

[whatwg] [CSSWG][css-lists-3] Updated WD of CSS Lists Level 3

[fantasai]

The CSS WG has published an updated Working Draft of the
CSS Lists Module Level 3:

https://www.w3.org/TR/css-lists-3/

The Lists module covers list-styling options such as changing counter styles
and marker position as well as automatic counters and numbering; Level 3
introduces
  * integration with the new counter styles in CSS Counter Styles L3
  https://www.w3.org/TR/css-counter-styles-3/
  * additional control over marker positioning
  * styling via the ::marker pseudo-element introduced in css-pseudo-4
  * the new counter-set property
  * the automagic 'list-item' counter, which allows referencing and manipulating
the default list numbers

Note in particular that the 'list-item' counter interacts with the automatic
numbering features in the HTML spec. See
  https://www.w3.org/TR/css-lists-3/#list-item-counter

This is a significant and overdue redraft of Level 3: some experimental features
were dropped and the whole draft has been streamlined and tightened up, shifting
the draft from "please don't try to implement this" to "pretty reliable". 
However,
there are still some open issues against Chapter 4 (Automatic Numbering with
Counters), and we recommend continuing to use CSS2.1 as the definitive reference
for those features until L3 has been fully synchronized with it.

Significant changes are listed at:

  https://www.w3.org/TR/2019/WD-css-lists-3-20190425/#changes-20140320

Many thanks to Mozilla (Mats Palmgren, David Baron, and Emilio Cobos Álvarez)
for their detailed feedback this round.

Please review the draft, and send any comments to the www-style mailing list,
, prefixed with [css-lists-3] (as I did on this message) or
(preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

Re: [whatwg] [CSSWG][selectors-4] Updated WD of Selectors L4

[fantasai]

On 11/21/18 2:33 PM, Andrew Fedoniouk wrote:

:blank is quite bad as a state name

For example   shall be considered as not :blank as it has initial value 
deliberately set to blank string (empty string allowed).


This would match :blank.

~fantasai

[whatwg] Can u read me?

[marta . cakes]

Hi all!

Can u read me? I subscribed the mailing list but not sure if i did it well.

My email is marta.ca...@sandbox.peppermalware.com

Thank u

[whatwg] [CSSWG][selectors-4] Updated WD of Selectors L4

[fantasai]

The CSS WG has published an updated Working Draft of Selectors Level 4:

  https://www.w3.org/TR/selectors-4/

Selectors are patterns that match against elements in a tree and are used
as a core part of CSS and in DOM methods such as .querySelector()

This update adds, drops, and renames a number of selectors:
  * zero-specificity pseudo-class named :where()
  * :matches() renamed to :is()
  * :blank defined to select empty user input elements
  * :empty redefined to ignore whitespace-only text nodes
  * :drop() dropped due to removal of support in HTML
  * Added case-sensitive attribute value matching flag

In addition, the specificity rules for :is() and :nth-child() were altered
to use the most specific selector argument rather than the most specific
selector that happened to match. See
  https://www.w3.org/TR/selectors-4/#specificity-rules
and discussion in
  https://github.com/w3c/csswg-drafts/issues/1027

Changes since the February 2018 WD are all listed at:
   https://www.w3.org/TR/2018/WD-selectors-4-20181121/#changes

One major issue that's open is redefining the way invalid selectors are
handled within `:is()` and similar pseudo-classes to ignore unknown
selectors rather than invalidating the entire style rule. See
  https://github.com/w3c/csswg-drafts/issues/3264

Another series of open issues concerns the :visited pseudo-class and
how to balance security concerns with usability requirements. See e.g.
  https://github.com/w3c/csswg-drafts/issues/3012
  https://github.com/w3c/csswg-drafts/issues/2263

Please review the draft, and send any comments to the CSSWG mailing list,
, prefixed with [selectors-4] (as I did on this
message) or (preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

[whatwg] [CSSWG][css-display-3] CR of CSS Display Level 3

[fantasai]

The CSS WG has published a Candidate Recommendation and invites
implementations of the CSS Display Module Level 3:

https://www.w3.org/TR/css-display-3/

CSS Display describes how the CSS formatting box tree is generated
from the document element tree and defines properties that control
the types of boxes thus generated.

New features since Level 2 include:
  * new two-keyword syntaxes for various display types
  * inline list-items
  * run-ins
  * 'display: contents' to replace an element with its contents

The draft also features
  * A normative description of the CSS box generation model
https://www.w3.org/TR/2018/CR-css-display-3-20180828/#intro
  * Definitions for blockification and inlinification
https://www.w3.org/TR/2018/CR-css-display-3-20180828/#transformations
  * A glossary of key box model terms (largely extracted from CSS2.1)
https://www.w3.org/TR/2018/CR-css-display-3-20180828/#glossary

Significant changes since earlier drafts are listed at:
  https://www.w3.org/TR/2018/CR-css-display-3-20180828/#changes
Disposition of comments:
  https://drafts.csswg.org/css-display-3/issues-wd-2017

Please review the draft, and send any comments to the www-style list,
, prefixed with [css-display] (as I did on this
message) or (preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

Re: [whatwg] Security: emphasize that subdomain is not enough for user provided scriptable content

[Jonathan Zuckerman]

These domains are used specifically because they are reserved for that use
- https://www.iana.org/domains/reserved

If a non-reserved domain is used, it could be bought up by anyone and have
its content changed to something not appropriate for linking from official
spec documents.

The note is technically correct, but perhaps it could be written
differently to more clearly point out the necessity of a different TLD?

On Tue, Aug 28, 2018 at 8:33 AM Mikko Rantalainen <
mikko.rantalai...@peda.net> wrote:

> The page
>
>https://html.spec.whatwg.org/dev/iframe-embed-object.html
>
> contains an example that has "usercontent.example.net" instead of e.g.
> "video.example.com" used in the same chapter. It does have a warning
> saying
>
> > It is important to use a separate domain so that if the attacker
> > convinces the user to visit that page directly, the page doesn't run
> > in the context of the site's origin, which would make the user
> > vulnerable to any attack found in the page.
>
> but I think this should specifically mention that using a subdomain is
> not enough because JavaScript can lift any domain restrictions if only
> the subdomain is different. This difference may not be immediately
> obvious to casual reader especially because both examples also have
> different subdomains which is easier to notice.
>
> I'm not sure how wording should be put because technically
> "example.com." is subdomain of "com." top level domain. And we have
> stuff such as "co.uk.", which makes things even hairier.
>
> I guess that the spec would like to use .example.* domains in all the
> examples but perhaps one could use something more explicit such as
>
> https://example-usercontent.com/...
>
> for this example in addition to being more explicit about subdomains in
> the warning. That would prevent even casual reader from mixing
> a.example.com and b.example-usercontent.com.
>
> --
> Mikko
>

[whatwg] Security: emphasize that subdomain is not enough for user provided scriptable content

[Mikko Rantalainen]

The page

  https://html.spec.whatwg.org/dev/iframe-embed-object.html

contains an example that has "usercontent.example.net" instead of e.g. 
"video.example.com" used in the same chapter. It does have a warning saying



It is important to use a separate domain so that if the attacker
convinces the user to visit that page directly, the page doesn't run
in the context of the site's origin, which would make the user
vulnerable to any attack found in the page.


but I think this should specifically mention that using a subdomain is 
not enough because JavaScript can lift any domain restrictions if only 
the subdomain is different. This difference may not be immediately 
obvious to casual reader especially because both examples also have 
different subdomains which is easier to notice.


I'm not sure how wording should be put because technically 
"example.com." is subdomain of "com." top level domain. And we have 
stuff such as "co.uk.", which makes things even hairier.


I guess that the spec would like to use .example.* domains in all the 
examples but perhaps one could use something more explicit such as


   https://example-usercontent.com/...

for this example in addition to being more explicit about subdomains in 
the warning. That would prevent even casual reader from mixing 
a.example.com and b.example-usercontent.com.


--
Mikko

[whatwg] Fieldset interoperability work

[Simon Pieters]

Hello all,

In the interest of transparency. Bocoup is funded by Mozilla to work on
improving interoperability for the fieldset and legend elements. I will
work on this in the next few weeks.

In the whatwg/html repo, the issues for this project have the "topic:
fieldset" label.

https://github.com/whatwg/html/issues?utf8=%E2%9C%93=label%3A%22topic%3A+fieldset%22

In the web-platform-tests/wpt repo, PRs relevant for this project have the
"html-fieldset" label.

https://github.com/web-platform-tests/wpt/issues?utf8=%E2%9C%93=label%3Ahtml-fieldset

As part of addressing some of the issues, I've started drafting a spec
proposal, which I will later turn into a pull request.

https://docs.google.com/document/d/1JM0YmKNRmhl1nEqcg_M_KlxBg_q7LIz9xgzmbrHp34o/edit?usp=sharing

I'm using the following spreadsheet to coordinate this work:

https://docs.google.com/spreadsheets/d/1y8LAcvyna4ph2WQvTb4gjOIvEEGzm-zIBOVYuyDfneU/edit?usp=sharing

cheers,
-- 
Simon Pieters
https://bocoup.com/

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

[fantasai]

On 12/25/2017 02:54 AM, fantasai wrote:

The CSS WG has published an updated Candidate Recommendation of the
CSS Scroll Snapping Module Level 1:

     https://www.w3.org/TR/css-scroll-snap-1/

This module contains features to control panning and scrolling behavior
with “snap positions”.

This update renames the 'scroll-snap-margin' property to 'scroll-margin'
and applies it also to the target element of scrolling operations such
as scrollIntoView(), focus(), and navigating to #fragment.

Note that 'scroll-padding' is already applied generally:
   https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding

A related concern was brought up that some DOM APIs define scrolling to
an element in a way that conflicts with scroll-snapping; such APIs should
allow for an element's snap position, if defined, to dictate the position
of an element to the viewport if no explicit argument is given to the
contrary.

Significant changes are listed at:

   https://www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes


Sorry, that URL should be

  https://www.w3.org/TR/2018/CR-css-scroll-snap-1-20180814/#changes

~fantasai

Re: [whatwg] Adding "ipfs" to the safelisted schemes

[L. David Baron]

On Saturday 2018-07-14 21:37 +0200, Mathias Rangel Wulff wrote:
> Hi Domenic
> 
> Thank you for getting back to me.
> 
> > Without implementer interest, there's not much we can do on the spec
> side.
> 
> Is it correctly understood that with "implementers" you refer to the team
> behind each browser implementation? Firefox whitelisted "ipfs" as a safe
> scheme in January 2018:
> https://hg.mozilla.org/mozilla-central/rev/c2cb8a06bcf1

I believe this is a different whitelist, related to Web Extensions.
I think the actual list Firefox uses for registerProtocolHandler is
based on the following set of preferences:
https://searchfox.org/mozilla-central/search?q=network.protocol-handler.external=
by the implementation which I believe lives here:
https://searchfox.org/mozilla-central/source/browser/components/feeds/WebContentConverter.js

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)

Re: [whatwg] Adding "ipfs" to the safelisted schemes

[Mathias Rangel Wulff]

Hi Domenic

Thank you for getting back to me.

> Without implementer interest, there's not much we can do on the spec
side.

Is it correctly understood that with "implementers" you refer to the team
behind each browser implementation? Firefox whitelisted "ipfs" as a safe
scheme in January 2018:
https://hg.mozilla.org/mozilla-central/rev/c2cb8a06bcf1

I know that Firefox is more "out there" being a trailblazer for new
features but it does indicate that  there is a case for adding "ipfs" to
the safelisted schemes provided in the HTML specs 8.7.1.3 "Custom scheme
handlers: the registerProtocolHandler() method"  (
https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme)

> Unfortunately, we haven't had much success in getting implementers to
update this list.

Pressure is built one drop at a time.

- Mathias Rangel Wulff

Re: [whatwg] Adding "ipfs" to the safelisted schemes

[Pascal Precht]

All for it!

On Thu, Jul 12, 2018 at 4:38 PM Mathias Rangel Wulff  wrote:

> To whom it might concern
>
> In short, I suggest adding "ipfs" to the safelisted schemes provided in the
> HTML specs 8.7.1.3 "Custom scheme handlers: the registerProtocolHandler()
> method"  (
> https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme
> )
>
> The idea of building a decentralised web was core in the early days of what
> we now know as the internet. Today the landscape of the internet has vastly
> changed; centralised megahubs of content has turned the client-server
> distribution model into a much more throttle prone and censorable beast
> than ever imagined.
>
>
>
> The InterPlanetary File System (IPFS) is a peer-to-peer hypermedia protocol
> where content is stored in a distributed manner and addressed by content
> identifiers. The project has gained much traction since its inception in
> 2014, and vast amounts of data are now stored in this parallel web of peers
> providing a genuinely decentralised infrastructure for exchanging data.
>
> To enhance mainstream adoption the regular browser experience needs to
> bridge how content is accessed via IPFS. Browser plugins already exists,
> but implementation and fallback mechanisms are limited due to existing (and
> legitimate) safety concerns.
>
> Adding "ipfs" to the safelisted schemes of the registerProtocolHandler
> method will significantly improve the seamless adoption of a censor
> resistant and decentralised internet, bringing the user experience closer
> to what was originally envisioned for the world wide web.
>
> As an example, the browser Brave (brave.com) is now working on native
> support for providing content via IPFS as a seamlessly integrated part of
> the user experience. Building upon The Chromium Project (chromium.org) a
> whitelisting of "ipfs" as a safe scheme will be a step towards Brave
> providing its users with a more decentralised web.
>
> For more information about IPFS, please visit https://ipfs.io
>
>
> - Mathias Rangel Wulff
>


-- 
/pp

[whatwg] Adding "ipfs" to the safelisted schemes

[Mathias Rangel Wulff]

To whom it might concern

In short, I suggest adding "ipfs" to the safelisted schemes provided in the
HTML specs 8.7.1.3 "Custom scheme handlers: the registerProtocolHandler()
method"  (
https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme)

The idea of building a decentralised web was core in the early days of what
we now know as the internet. Today the landscape of the internet has vastly
changed; centralised megahubs of content has turned the client-server
distribution model into a much more throttle prone and censorable beast
than ever imagined.



The InterPlanetary File System (IPFS) is a peer-to-peer hypermedia protocol
where content is stored in a distributed manner and addressed by content
identifiers. The project has gained much traction since its inception in
2014, and vast amounts of data are now stored in this parallel web of peers
providing a genuinely decentralised infrastructure for exchanging data.

To enhance mainstream adoption the regular browser experience needs to
bridge how content is accessed via IPFS. Browser plugins already exists,
but implementation and fallback mechanisms are limited due to existing (and
legitimate) safety concerns.

Adding "ipfs" to the safelisted schemes of the registerProtocolHandler
method will significantly improve the seamless adoption of a censor
resistant and decentralised internet, bringing the user experience closer
to what was originally envisioned for the world wide web.

As an example, the browser Brave (brave.com) is now working on native
support for providing content via IPFS as a seamlessly integrated part of
the user experience. Building upon The Chromium Project (chromium.org) a
whitelisting of "ipfs" as a safe scheme will be a step towards Brave
providing its users with a more decentralised web.

For more information about IPFS, please visit https://ipfs.io


- Mathias Rangel Wulff

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-25 09:08, Richard Maher wrote:
Splitting things into a whole bunch of APIs and then trying to get permissions working for all of them 
is going to be a huge pain IMO.


There is no "going to be" Roger. You are not embarking on a green-field 
development or brain-storming "The Web". We are where we are. I don't 
care if people want to change things but it is DEFINITELY out-of-scope 
for the Background Geolocation implementation.


I was a unaware you where the moderator of the Background Geolocation 
specs or similar. In that case my apologies, I had no intention of 
pushing things into the specs that do not belong there (it's bad enough 
in politics).


But I don't understand what you mean by "We are where we are" or why you 
are against brain storming and I had to lookup the greenfield term but I 
am unsure if you mean untapped market, new software projects, 
undeveloped land or if you are referring to an area in Manchester (yes 
I'm being an asshat on that last one).


I'm also unsure if you are being sarcastic or are actually trying to 
dictate what I should or should not do. If you are upset that things 
veered off topic then I'm sorry about that.


To me it looks like you want a commercial backend solution for Uber or 
Dominos or similar (not end users). Surely these can run apps on tablets 
or smartphones? Browsers are pretty good but for operational software 
you want reliability and a consumer browser despite the amazing efforts 
of the developers so far is not that stable yet. If "always on in the 
background" is key to a business then a OS run background service is 
exactly what is needed.


If you need certain functionality implemented and your project is 
waiting on this then I suggest you make a OS native app instead before 
your competitors sale past you.


Looking through the WHATWG history I do not like what I see so I'm going 
to stop communicating regarding this topic, and most likely future 
topics by you, you come across as excessively abrasive and I'd rather 
not have to deal with that. You've said in the past that you felt you 
have been stifled or censored by others, well now you have succeeded in 
stifling me. I'm having difficulties communicating with you, I can't 
even imagine trying to work on code or standards implementations with you.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Philipp Serafin]

2018-03-25 6:29 GMT+02:00, Roger Hågensen :
> On 2018-03-24 22:32, Andy Valencia wrote:
[...]
>> We're all well aware of the behaviors which make browsers adopt such
>> defensive measures.  Are we looking at enough use-cases to think about
>> some
>> sort of general authorization for background resource consumption, rather
>> than
>> continuing the point solution approach?
>
[...]
> I've kinda derailed this topic and we've got a three headed hydra now.
> Geolocation background tracking.
> Environment/general sensor API with background logging.
> Background task permission API for sensors or other general purposes.
>
> Regardless of use cases or apis is tied into this, one thing is clear.
> The user must either implicitly or explicitly initiate or agree to
> background processing. Some form of UI would be needed to give oversight
> over background browser tasks too.
[...]

I think a general solution for background processing would be
absolutely desirable. Some additional use-cases would be chats or
multiplayer games - i.e. realtime applications where it's important to
know whether a current user is still present or has dropped out.

2018-03-24 22:12 GMT+01:00, Roger Hågensen :

[...]

>> E.g., a web page could ask the browser to continously record location
>> changes and - at some time at the browser's discretion - push a list of
>> recorded changes to the page.
>
> Hmm! It might.
> certainly it makes sense to cache location coords since the device may
> not have a internet connection during the entire time.
>
> In practice it would only need a internet connection at the time of data
> submission to the site of the webapp, the rest of the time it could be
> "offline".
>
>> This would allow the browser to record locations changes with reasonably
>> accuracy *without* waking up service workers.
>
> THis part I'm unsure of. Should it be a webapp or a client feature with
> a API for webapps?

[...]

By "push" I meant triggering a javascript event/callback in the web
page that requested the recording in the first place. (Either directly
in the corresponding tab/window or in a service worker)

I didn't mean that the browser itself should send the recording over
the network.
(Though it would certainly be useful if the web page could indicate
"wait until there is internet before you call me back", to simplify
the case where *the page* then immediately passes-on the result to a
server)

(Anyway, this whole idea seems now obsolete in light of the current
discussion, so this is just for the record.)

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-25 07:17, Richard Maher wrote:
  If that makes sense for your App the background-fetch already caters 
for posting location updates to a fleet manager.

...
  If delayed Batch Processing is acceptable to your site and you don't 
want geofences then good luck.

...

  TravelManager register() and unRegister()


I had to look up fleet manager and travelmanager. These are business 
terms. I did not consider fleet management, nor did I consider targeted 
traveling advertising/upselling (travelmanager?).


I was looking at this from a non-commercial user standpoint as well as 
scientific standpoint. Hence why I mentioned "crowd sourcing" weather 
data and geolocation from smart devices via a webapp, or a health and 
fitness training app (pulse, distance, altitude etc), or 
health/wellbeing (baby monitoring, pet monitoring).


But regardless of the intened use or purpose. Splitting things into a 
whole bunch of APIs and then trying to get permissions working for all 
of them is going to be a huge pain IMO.


A general purpose permission system and a general purpose sensor api 
(that can gather gps and various other things like ambient temperature 
or pulse) would be a better long term goal. It would also be less likely 
to screw up security this way.


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-25 07:17, Richard Maher wrote:


This would allow the browser to record locations changes with
reasonably
accuracy *without* waking up service workers.


  If you don't like how ServiceWorkers cater for the Fetch API than 
please take it offline with Jake and W3C.


Um. You missquoted, that wasn't me who said that.


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-24 22:32, Andy Valencia wrote:

There are lots of apps using long-polling which would also like
to have some explicit (standards based) answers to their needs
to run when not the current tab--messaging and telemetry apps,
for instance.

And here we are thinking about a hand crafted solution for GPS backgrounding.

We're all well aware of the behaviors which make browsers adopt such
defensive measures.  Are we looking at enough use-cases to think about some
sort of general authorization for background resource consumption, rather than
continuing the point solution approach?


Good point. And my example of a environment API was flawed as I just 
realized that a heart (pulse) sensor might be highly beneficial to tie 
into time and GPS and temperature and other sensor data.
All this stuff could be lumped into a sensor API (or is there a existing 
one?)


Another related example would be a loudness tracker, which would use the 
Microphone to record and calculate a loudness.
One particular such use could be a baby monitor, letting you see how 
much noise/crying the baby does, maybe add in temperature or moisture 
sensor data if available. Or replace baby with dog or cat to detect 
barks or meowing while the pet owner is out of the house.


A sensor api and a background permission api should probably be separate 
as I'll assume there might be other non-sensor uses that a user might 
want to do background processing.
Perhaps a server uptime app, having the app reliably prod a server would 
be such a use case.


Obviously a dedicated native app could do this much better, but it's a 
lot quicker to throw something together as a web app. And there is 
little to no need to roll out updates unlike native apps.


I guess this is a chicken and an egg situation. You won't see use cases 
unless it's possible to actually implement them. It's not as much a 
"Should this be possible?" question as it is a "Why isn't this 
possible?" question.


I've kinda derailed this topic and we've got a three headed hydra now.
Geolocation background tracking.
Environment/general sensor API with background logging.
Background task permission API for sensors or other general purposes.

Regardless of use cases or apis is tied into this, one thing is clear. 
The user must either implicitly or explicitly initiate or agree to 
background processing. Some form of UI would be needed to give oversight 
over background browser tasks too.
While I did angle towards smart phones here there is no reason why a 
desktop can't also run background webapps, and there battery capacity is 
a non-issue (usually).


Sorry for murkying the waters further on this.

--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Andy Valencia]

[Philipp Serafin :]
> If this problem is specific to the "track a route" use-case, and the
> use-case is sufficiently widespread, would a dedicated "route recording"
> API make sense?
>
> E.g., a web page could ask the browser to continously record location
> changes and - at some time at the browser's discretion - push a list of
> recorded changes to the page.

Playing audio is already a special case; the tab with the active
 element will almost certainly not have its setTimeout's
honored until it comes back to foreground.  But the "ended" event
will get to run, at least long enough to move to the next track.
In fact, it can XHR and get to run/play-next on the completion.

(But wait, on slower tablets Firefox doesn't allow quite enough
CPU to keep the background mp3 playing.  Oops.)

Or think about the iterations in the space of downloads (XHR,
service worker background fetch, background sync).

There are lots of apps using long-polling which would also like
to have some explicit (standards based) answers to their needs
to run when not the current tab--messaging and telemetry apps,
for instance.

And here we are thinking about a hand crafted solution for GPS backgrounding.

We're all well aware of the behaviors which make browsers adopt such
defensive measures.  Are we looking at enough use-cases to think about some
sort of general authorization for background resource consumption, rather than
continuing the point solution approach?

$0.02,
Andy Valencia

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-24 21:15, Philipp Serafin wrote:

If this problem is specific to the "track a route" use-case, and the
use-case is sufficiently widespread, would a dedicated "route recording"
API make sense?

E.g., a web page could ask the browser to continously record location
changes and - at some time at the browser's discretion - push a list of
recorded changes to the page.


Hmm! It might.
certainly it makes sense to cache location coords since the device may 
not have a internet connection during the entire time.


In practice it would only need a internet connection at the time of data 
submission to the site of the webapp, the rest of the time it could be 
"offline".



This would allow the browser to record locations changes with reasonably
accuracy *without* waking up service workers.


THis part I'm unsure of. Should it be a webapp or a client feature with 
a API for webapps?



It would also provide some hooks for privacy controls: A browser could show
a status indicator whenever it's in "GPS recording" mode. It could also
notify the user when it's about to push the recorded route to the page and
possibly even show the route for confirmation.


I certainly see the charm and practicality in a webapp asking the client 
(browser) to start logging GPS coords (it must be user initiated at some 
point though, like a button/link click).

And then the same when stopping it.

A _start function and a _stop function and a _get function would be all 
that is needed.


The _stop function should be self explanatory. The _start function would 
allow a argument of milliseconds (or is seconds enough granularity?), 
which specifies the interval the client should use to record the current 
GPS and other info.


The _get function of such a API would just return a JSON array of GPS 
objects, with cords, height and timestamp of the reading, with future 
expandability for including stats like pressure and moisture and 
temperature (can't think of anything else).
For a cyclist/runner/driver/boater the coords might be useful (to get 
distance and route traveled). For a camper or woodsman or farmer or who 
knows what else the moisture and temperature and pressure and elevation 
may be valuable (the GPS coords would be almost identical for each 
reading though).


I'm not sure if this would fit under a geolocation API though, perhaps 
more under a environmental API (where GPS/elevation is just one of many 
data).


Since the user explicitly (or implicitly) press start there is no need 
to ask permission.
But there should be a possibility to ask for site permisssion and have 
the webapp autostart, this would allow to run the wwebapp in a browser 
24/7 and have it send "live" data to a server. This could make a 
smartphone a temporary weather station (a smartphone could have a 
external "weather sensor box" connected for example, providing the 
sensor input for this API, the browser would just see it as OS provided 
sensor data).


Sure a Raspberry Pi or some other IOT with some scripting can do this 
better, but just plopping a smart device to a large battery pack or 
mains power and leaving it over the night sending live data to a server 
could be useful. Hundreds if not thousands of these round the world 
could supplement weather research/sites with that data.



I'd suggest this as a way to detect if such a API is available
if ("environment" in navigator) {
  /* environment API is available */
} else {
  /* environment API IS NOT available */
}
It would really need to be it's own thing instead of adding to the 
geolocation, there should be no issues with both coexisting.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Philipp Serafin]

If this problem is specific to the "track a route" use-case, and the
use-case is sufficiently widespread, would a dedicated "route recording"
API make sense?

E.g., a web page could ask the browser to continously record location
changes and - at some time at the browser's discretion - push a list of
recorded changes to the page.

This would allow the browser to record locations changes with reasonably
accuracy *without* waking up service workers.

It would also provide some hooks for privacy controls: A browser could show
a status indicator whenever it's in "GPS recording" mode. It could also
notify the user when it's about to push the recorded route to the page and
possibly even show the route for confirmation.



Roger Hågensen  schrieb am Sa., 24. März 2018,
19:49:

> On 2018-03-19 00:25, Richard Maher wrote:
> > FYI This question on StackOverflow has now had over 1000 views: -
> >
> https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain
> >
> > Please explain why nothing is happening.
> It has a accepted solution.
>
> But one key issue is that browers throttle down or even pause inactive
> windows/background tabs.
> Partly blame digital currency mining for this, blame the rest on bad
> programmers running full tilt when they don't need to and DDOS trojans
> for the rest.
>
> I haven't looked this up, but is there a way to ask the user for
> permission to run as a background app without performance restrictions?
> That is the only way I forsee this working across all browsers.
>
>
>
>
>
> --
> Unless specified otherwise, anything I write publicly is considered
> Public Domain (CC0). My opinions are my own unless specified otherwise.
> Roger Hågensen,
> Freelancer, Norway.
>

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

[Roger Hågensen]

On 2018-03-19 12:49, Anne van Kesteren wrote:

On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen
<mikko.rantalai...@peda.net> wrote:

The spec should specify one way or the other for this corner case.


Agreed, we're tracking this in
https://github.com/whatwg/html/issues/3520. If anyone would like to
help clarify the prose in the form of a pull request or wants to make
a strong case for Firefox's behavior, that'd be much appreciated.
Is it possible the Firefox devs assumes that 0,0,0 infers this to be a 
"unknown" progress state?
On Windows UI this tends to be shown as a a full but "pulsing" progress 
bar, in a looping animation.
But I've seen UI design that also fills up the progress then clears it, 
in a looping animation.


Thouigh one could easily "animate" this via just setting the values, so 
even if 0,0,0 was speced to always show nothing one could still do the 
"unknown"! behaviour.


Personally I think 0,0,0 should not only be empty but the actual 
progress bar itself should not be drawn as it's in a non-state if you 
know what I mean.

Which probably will be changed by some javascript moments later.

Treat 0,0,0 as it being there but just non-visible maybe?

Although I'm almost tempted to say that 0,0,0 should throw a warning in 
the dev console log that a valid range must be set and that the value 
must be within (inclusive) that range.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-19 00:25, Richard Maher wrote:

FYI This question on StackOverflow has now had over 1000 views: -
https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain

Please explain why nothing is happening.

It has a accepted solution.

But one key issue is that browers throttle down or even pause inactive 
windows/background tabs.
Partly blame digital currency mining for this, blame the rest on bad 
programmers running full tilt when they don't need to and DDOS trojans 
for the rest.


I haven't looked this up, but is there a way to ask the user for 
permission to run as a background app without performance restrictions?

That is the only way I forsee this working across all browsers.





--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

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

[Anne van Kesteren]

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

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


-- 
https://annevankesteren.nl/

[whatwg] Popular Background Geolocation question on StackOverflow

[Richard Maher]

FYI This question on StackOverflow has now had over 1000 views: -
https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain

Please explain why nothing is happening.

Re: [whatwg] META and bookmarking

[Andy Valencia]

Thank you very much for pointing me at the right bits of existing
standards.

Matthew Wronka's reference of a "canonical relationship" and
RFC6596 is very much on target.  rel=canonical should do as much
as I could hope for in any case.

I of course considered an initial landing page, but UX pushes strongly
where the 99.999% case is not the one which should require the extra
click.  I'll certainly have the canonical link specified, and hope
for the best.  Perhaps even, as you say, submit a ticket to a
browser or two.

Thanks again,
Andy Valencia

[whatwg] [CSSWG][css-sizing-3] Updated WD of Sizing L3, Last Call for Comments

[fantasai]

The updated text regarding intrinsic sizing of replaced elements
might be of interest here:
  https://www.w3.org/TR/css-sizing-3/#intrinsic
  https://www.w3.org/TR/css-sizing-3/#min-content-zero

There's also an open issue about sizing iframes to their content:
  https://github.com/w3c/csswg-drafts/issues/1771
It's tagged against Level 4, but we did just add handling for
 and .

~fantasai

 Forwarded Message 
https://lists.w3.org/Archives/Public/www-style/2018Mar/0001.html

The CSS WG has published an updated Working Draft of the
CSS Intrinsic and Extrinsic Sizing Module Level 3:

  https://www.w3.org/TR/css-sizing-3/

This module extends the CSS sizing properties with keywords that
represent content-based "intrinsic" sizes and context-based
"extrinsic" sizes, allowing CSS to more easily describe boxes
that fit their content or fit into a particular layout context.

Significant changes are listed at:
  https://www.w3.org/TR/2018/WD-css-sizing-3-20180304/#changes
and include
  * merging in the full definitions of all sizing properties
from CSS2.1 (min/max?-width/height) and css-ui (box-sizing)
  https://www.w3.org/TR/css-sizing-3/#specifying-sizes
  * more thorough definition of replaced element intrinsic sizes
  https://www.w3.org/TR/css-sizing-3/#intrinsic
and percentage sizing within indefinite containers
  https://www.w3.org/TR/css-sizing-3/#percentage-sizing
  * defining min-content and max-content to work on form controls
  * deferring the 'stretch' and 'fit-content' keywords to Level 4
(whose focus will be defining these keywords and 'contain')

Open issues include:
  * Adding more illustrations (help wanted)
  https://github.com/w3c/csswg-drafts/issues/1938
  * Working out how calc() values including percentages work
on margins/padding/width/height/gaps when the container size
depends on this child box’s size (input wanted)
  https://github.com/w3c/csswg-drafts/issues/2297
That is, currently when we are calculating the size of the
container we treat a percentage size as zero. Then once
the size of the container is established, we resolve the
percentage against that size. What should happen if we have
a size as calc(20% + 10px)? Do we ignore the 10px or honor
it in some way? What about calc(10px - 20%)?
See 
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-sizing-3
for all open issues.

We expect to transition to CR soon, so this draft effectively
marks the beginning of a last call for comments period; we
will be accepting comments at least through the end of March,
and depending on the state of the draft, aim to transition to
CR sometime in April. (We will of course process comments
during CR as well, but would prefer to get them sooner rather
than later.)

(Note that the min-content and max-content keywords have already
been officially cleared for shipping prior to CR by the CSSWG
  https://lists.w3.org/Archives/Public/www-style/2015Aug/0109.html
since their syntax was stable and their behavior was tied to
behavior exposed in existing CSS2.1 features.)

Please review the draft, and send any comments to this mailing list,
, prefixed with [css-sizing] (as I did on this
message) or (preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

Re: [whatwg] ServiceWorker bottle-neck design flaw - MS Edge to the rescue?

[Richard Maher]

EDIT 1

Ok, it might have been Safari/Webkit but reading this
 it looks like 1
process for all ServiceWorker threads plus another to monitor/start/stop,
but only one simultaneous SW instance per domain (plus that dodgy iFrame
logic webkit has got going on)

So if neither Webkit or Edge do what my memory tells me then is it not a
good performance idea? (Barring reduced hit rate on SW recycling)

EDIT 2

On third thoughts, the fact that everything in a ServiceWorker is
Asynchronous or verbotten means Fetch, Push, Travel, events can all
multiplex to the same SW instance without much performance degradation.

Oh Well, I'm back to "Stuffed if I know why no one is implementing the
TravelManager :-("

FWIW The WebKit implementation of shared memory buffer must surely
necessitate a Synchronous API? Breaking one of the major premises of SW
design?

EPILOG

I apologise for spamming the recipients here even though I did it
knowingly. I won't do it anymore. I didn't believe I was reaching an
audience so I just kept pulling leavers and pushing any and all buttons
available.

I have been made aware that, unbeknownst to me, some of the right people
were hearing what I had to say and the TravelManager idea was gaining
traction. To those people let me just say that I spent a fair bit of time
on the Brotkrumen Web App which demarcates UA Developer and Web Developer
contributions succinctly, provides smooth Google Map marker movement via
CSS transitions to get the mug punters looking and, most importantly, is a
fully working, fully documented, complete, sscce which provides real-time
feedback on the ratio of ServiceWorker instances to Geolocation updates!

If there is a open/tolerant forum where people discuss such things then
please let me know. Once again, *no one* can tell me there's anything wrong
with the idea. OTOH I can tell you heaps of things that are wrong with the
"alternative" WakeLock or Sensor ideas.

I also have a few good ideas for permissions/visibility on Background
Geolocation if anyone is interested.

BTW when I said repeatedly that I am happy to "go away" it was on the
proviso that the two issues I've been banging on about for two years were
implemented.

1) Broadcast notifications where the client/UA can subscribe to a Topic.
Once again W3C let us down but thanks to FCM we can access this much needed
functionality so I let it go.

2) Background Geolocation. As ShamWow guys says "It sells itself". Why,
WHY, *WHY* are people saying NO to this?


Cheers Richard


On Fri, Mar 2, 2018 at 11:22 AM, Richard Maher 
wrote:

> As you may be aware, I have been lobbying strongly here
> ,
> and here
> ,
> and especially over there
>  for the introduction of
> a background geolocation capability with Web Apps.
>
> So frustrated had I become that I spent the time to develop and document a
> POC example with everything UA developers and Web App developers need to do
> to implement background geolocation - documented sscce here
>  and, to
> date, no one can tell me there’s anything wrong with it.
>
> In this technical feed-back vacuum my mind began to ponder why, and then
> drifted to “Cui Bono?”, and ultimately to conspiracy theories. For example:
> - Phonegap/Cordova developers bribing W3C to sandbag BackgroundGeolocation
> efforts.
>
> But only today did it dawn on me like a bolt of lightning to the brain!
> There is a fundamental design flaw with the current ServiceWorker
> design/implementations in that there is only ONE per UA. Jake Archibald et
> al have been so blinkered with offline-first, cache, and the browser being
> a proxy-server that they will not tolerate anything else monopolizing the
> SW thread to the detriment of their fetch performance stats.
>
> But God Bless Edge, notwithstanding their tardy arrival on the scene, who
> I believe have specialist SW instances for PUSH, FETCH, A.N.Other. This is
>  *fantastic*!!!
>
> Just add another specialist instance “GeoLocation” and we’re away.
>
> Please don’t let self-interest stand in the way of this essential
> functionality. Let’s go!
>
> But my question here is this: - Can someone please confirm that Edge
> implements multiple, specialist SW instances?
>
> Cheers Richard Maher
>
>

[whatwg] ServiceWorker bottle-neck design flaw - MS Edge to the rescue?

[Richard Maher]

As you may be aware, I have been lobbying strongly here
,
and here
,
and especially over there  for
the introduction of a background geolocation capability with Web Apps.

So frustrated had I become that I spent the time to develop and document a
POC example with everything UA developers and Web App developers need to do
to implement background geolocation - documented sscce here
 and, to
date, no one can tell me there’s anything wrong with it.

In this technical feed-back vacuum my mind began to ponder why, and then
drifted to “Cui Bono?”, and ultimately to conspiracy theories. For example:
- Phonegap/Cordova developers bribing W3C to sandbag BackgroundGeolocation
efforts.

But only today did it dawn on me like a bolt of lightning to the brain!
There is a fundamental design flaw with the current ServiceWorker
design/implementations in that there is only ONE per UA. Jake Archibald et
al have been so blinkered with offline-first, cache, and the browser being
a proxy-server that they will not tolerate anything else monopolizing the
SW thread to the detriment of their fetch performance stats.

But God Bless Edge, notwithstanding their tardy arrival on the scene, who I
believe have specialist SW instances for PUSH, FETCH, A.N.Other. This is
*fantastic*!!!

Just add another specialist instance “GeoLocation” and we’re away.

Please don’t let self-interest stand in the way of this essential
functionality. Let’s go!

But my question here is this: - Can someone please confirm that Edge
implements multiple, specialist SW instances?

Cheers Richard Maher

[whatwg] It's BackgroundGeolocation Zeit!

[Richard Maher]

Richard Maher 
10:00 AM (2 minutes ago)
to Chaals, Ben, WHAT, Chaals, Natan, public-geoloca., ehsan, alia, jmann,
beidson, eoconnor, weinig, Kenji, jungkee.song
Mate, how does Background Geolocation get to bypass this narcissistic
obstructionism? Are there no adults at W3C? Oh, Mozilla pays a lot so we
have to have him?

Two years precious time squandered due to him and Jerk bloody Archibald. Is
there no accountability in your autonomous collectives?

Merit-based resource allocation?

Re: https://discourse.wicg.io/t/proposal-expose-geolocation-
to-service-workers/2588


marcosc 
22h


FYI, I’ve banned @Richard_Maher
 from
our discourse for repeated code of conduct violations.

If he returns under a different alias (which he tends to do), please let me
know.

Please refrain from engaging with him on Discourse or standards discussions.
1 Like


marcosc 
21h


I’ve also deleted @Richard_Maher 
 posts, as they are just noise.

Apologies to participants in this thread for not taking action sooner. This
individual has been trolling our community for a long time, and, despite
numerous pledges from him to behave - or claims that he will go away, he
keeps coming back.

"Noise"? Was there someone else that contributed anything useful? Fine, ban
me (again) but burn my books? Really?

How do you blokes live with yourselves :-(

BTW. I believe you should update your CoC more in line with the other
communist regime's banning of "disagree": -

“Disagree”.

This is what it prompts:

“Sorry, this content violates the laws and regulations of Weibo’s terms of
service.”
Just replace Weibo with W3C/IETF :-(

https://www.perthnow.com.au/technology/internet/chinas-
war-on-words-anything-be-it-a-phrase-or-picture-that-can-be-
used-to-insult-xi-has-been-banned-ng-a8e5a9d558b3ed0465e1fc020e2d6c2c


PS. I've heard that North Korea and the Church of Scientology are also
doing great things in the free-speech space.


On Tue, Feb 27, 2018 at 8:23 AM, Richard Maher 
wrote:

> I guess that's why, when I lived in Munich, the English cinema was packed
> with locals (who seemed to laugh at odd moments :-)
>
> Anyway what has to happen to get Background Geolocation up?
>
> On Tue, Feb 27, 2018 at 6:47 AM, Chaals Nevile  wrote:
>
>> You have no need to reproach yourself Chaals. If you dekete your post
>>> then I will have dekete mine then we’ll end up in a cycle of revisionism
>>> and book burning.
>>>
>>
>> It's a noble profesion with an honourable history
>>
>> C’mon, we were a little bit funny?
>>>
>>
>> Well yeah, but to be honest only a little bit. And only in English. I
>> watched Princess Bride once in Spanish and realised why my spanish friends
>> didn't think it was funny. The translation is shit - totally lacking in
>> grace, humour or style, as is far too often the case for translations into
>> spanish.
>>
>> cheers
>>
>

Re: [whatwg] Web Components face to face, Tokyo 5-6 March

[Takayoshi Kochi]

Hi,

This is a reminder for the F2F meeting next week.
(Sorry if you get multiple spams from different lists)

If you haven't registered your name at
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/18-03-Web-components.md
by the end of Tuesday this week (Feb. 27) (at your timezone).

We (host at Google Tokyo office) are collecting the list for distributing
security badges for
the building and the office for the guests, and we need your names for it.

If you have any last minute change on your travel after that, don't worry,
please let me (ko...@google.com) know.
We have some room for additional people.



On Thu, Feb 1, 2018 at 12:05 AM, Takayoshi Kochi  wrote:

> Hi,
>
> We will be holding a WebComponents F2F.
> Hosted at Google Japan, at Roppongi, Tokyo, Japan.
>
> The general information is available at:
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/
> meetings/18-03-Web-components.md
>
> The agenda is being discussed at:
> https://github.com/w3c/webcomponents/issues/713
>
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: [whatwg] META and bookmarking

[Roger Hågensen]

Add a link in the header and use rel=canonical which tells the browser 
that the link is the correct url.


If all modern browsers actually uses the canonical url when you bookmark 
a page I have no idea, ideally they should though. File a bug report 
with the browsers if they don't.


Do note that search engines consider a slightly different meaning for 
rel=canonical though.


I'm curious though why you do not want the users to bookmark the subpage 
but the portal page instead.


Maybe rethink the design so that the portal (aka landing page) actually 
does not auto redirect. Present a clickable image (href + image) that 
the user can click or tap on. That way they can bookmark the portal page 
before clicking onwards.


Also make sure the users can click a back button on the subpage to go 
back to the portal page (call it Index or Home or Portal or something).


If you do not control these subpages yourself (they are somebody elses 
sites) then no browser devs will ever let you hijack the bookmarking of 
those. In this case you have a Directory/Indexing/Portal site and the 
only solution is to wait for the user to click before you send them to 
the foreign site. That way they can bookmark the portal site.


If the destination url contains a referral id of sorts then it's the 
destination site's responsibility to remove it if it's single use.



I dare say that in the "majority" of cases if you are unable to do 
something on the web today it's because you are doing it the wrong way.
I say "majority" because there are bound to be cases where this is not 
true. But in your case you might need to re-evaluate the way you do the 
redirect.


Now, I haven't seen your portal site so I'm just making assumptions here 
so I apologise beforehand in case my assumptions are way off.


RH

On 2018-02-17 20:55, Andy Valencia wrote:

The problem is if you like the site and decide to bookmark it--
including a home screen bookmark on mobile.  You're off on
a transient URL, which is not the right one to bookmark.  On
a desktop browser you can go into the extended dialog and
hand-modify the URL (some users could, others not so much).
On mobile, it can be difficult--on some devices even impossible.
...
Thanks,
Andy Valencia


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

[whatwg] META and bookmarking

[Andy Valencia]

I'm in the throes of a media startup, and ran into one of those
issues which runs surprisingly deep.

Like many sites, my front page is a portal which sends the
user on to the actual source of content for that user on that
day.  In my case, it's a particular media server (after choosing
based on current load) plus a session token in the URL.  I've
been researching this, other cases are where the redirect URL reflects the
current day/edition/release.

The problem is if you like the site and decide to bookmark it--
including a home screen bookmark on mobile.  You're off on
a transient URL, which is not the right one to bookmark.  On
a desktop browser you can go into the extended dialog and
hand-modify the URL (some users could, others not so much).
On mobile, it can be difficult--on some devices even impossible.

I'm wondering if a  tag would be appropriate? This
would let a page which knows it's not a good long-term bookmark target to
suggest a better URL to use.  In its absence, of course
the current URL is used.

For security, you could claim that anywhere Bad it would send you
is a place the current page could have already sent you.  If the
page was served under HTTP, I guess a lame ISP could insert themselves.
Possibly recommend ignoring the value from non-HTTPS pages?  That
certainly aligns with Mozilla's stated intentions for future
features.

Thanks,
Andy Valencia

Re: [whatwg] Expose GeoLocation to workers #745

[Richard Maher]

Yeah that's what I thought :-(

On Tue, Feb 13, 2018 at 8:12 AM, Richard Maher 
wrote:

> Regarding the very recent comments following on from: -
> https://github.com/w3c/ServiceWorker/issues/745#issuecomment-344128148
>
> Can any of you please explain what is wrong with the complete POC solution
> here: -
> https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
>
> If the proposed solution is somehow deficient or not fit for purpose
> please let me know!
>
> I believe the permissions/user-visibility conundrums to be the only loose
> end.
>
> Please also note the plethora of use cases detailed by numerous people
> over the years that can be found here: -
> https://github.com/w3c/ServiceWorker/issues/745
>
> I do not understand Marcos' claim that there is little browser interest
> when Edge and Chrome are waiting on a specification to implement. Firefox
> already allows tracking of users in the background today.
>
> Cheers Richard Maher
>

[whatwg] Expose GeoLocation to workers #745

[Richard Maher]

Regarding the very recent comments following on from: -
https://github.com/w3c/ServiceWorker/issues/745#issuecomment-344128148

Can any of you please explain what is wrong with the complete POC solution
here: -
https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

If the proposed solution is somehow deficient or not fit for purpose please
let me know!

I believe the permissions/user-visibility conundrums to be the only loose
end.

Please also note the plethora of use cases detailed by numerous people over
the years that can be found here: -
https://github.com/w3c/ServiceWorker/issues/745

I do not understand Marcos' claim that there is little browser interest
when Edge and Chrome are waiting on a specification to implement. Firefox
already allows tracking of users in the background today.

Cheers Richard Maher

[whatwg] [CSSWG][selectors-4] Updated WD of Selectors Level 4

[fantasai]

The CSS WG has published an updated Working Draft of Selectors Level 4

https://www.w3.org/TR/selectors-4/

Selectors is a pattern-matching syntax for identifying sets of elements
in a document, and is used e.g. for applying CSS declarations to elements
in a document tree.

This publication brings the /TR draft up-to-date with all of the WG
resolutions since 2013. Significant changes are summarized at:
  https://www.w3.org/TR/2018/WD-selectors-4-20180201/#changes

This specification is now in the Refining stage: we don't expect any large
changes prior to CR, but will be continuing to address issues. Most features
are well-scoped, with significant open issues described in the draft to
solicit directed feedback.

One major focus of the next round of edits will be to update and improve
cross-references between Selectors and other Web standards (in coordination
with the editors of the DOM and HTML standards at WHATWG). If any of you
know of other specifications with incoming references to Selectors, please
let us know so that we can accommodate them, too!

In the meantime, please review the draft. You can send any comments to the
www-style list <www-st...@w3.org>, prefixed with [selectors-4] (as I did on
this message) or (preferably) file them in the CSSWG GitHub repository at
  https://github.com/w3c/csswg-drafts/issues
We're hoping to address the remaining issues and issue a CR in the upcoming
months (but likely not before April).

Follow-ups to www-style.

For the CSS WG,
~fantasai

[whatwg] Web Components face to face, Tokyo 5-6 March

[Takayoshi Kochi]

Hi,

We will be holding a WebComponents F2F.
Hosted at Google Japan, at Roppongi, Tokyo, Japan.

The general information is available at:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/18-03-Web-components.md

The agenda is being discussed at:
https://github.com/w3c/webcomponents/issues/713

-- 
Takayoshi Kochi

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

[Anne van Kesteren]

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

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


-- 
https://annevankesteren.nl/

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

[fantasai]

The CSS WG has published an updated Candidate Recommendation of the
CSS Scroll Snapping Module Level 1:

https://www.w3.org/TR/css-scroll-snap-1/

This module contains features to control panning and scrolling behavior
with “snap positions”.

This update renames the 'scroll-snap-margin' property to 'scroll-margin'
and applies it also to the target element of scrolling operations such
as scrollIntoView(), focus(), and navigating to #fragment.

Note that 'scroll-padding' is already applied generally:
  https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding

A related concern was brought up that some DOM APIs define scrolling to
an element in a way that conflicts with scroll-snapping; such APIs should
allow for an element's snap position, if defined, to dictate the position
of an element to the viewport if no explicit argument is given to the
contrary.

Significant changes are listed at:

  https://www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes

Disposition of comments:

  https://drafts.csswg.org/css-scroll-snap-1/issues-cr-2016-08

Please review the draft, and send any comments to this mailing list,
, prefixed with [css-scroll-snap] (as I did on this
message) or (preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai

Re: [whatwg] Further working mode changes

[Roger Hågensen]

On 2017-12-18 11:47, Anne van Kesteren wrote:
> Last week we made some further refinements to the way the WHATWG
> operates and are pleased that as a result Microsoft now feels
> comfortable to participate:
>
>https://blog.whatwg.org/working-mode-changes
>https://blog.whatwg.org/copyright-license-change

I'd like to express my thanks to you and everyone else involved for the 
work you do on this. It's appreciated.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

[whatwg] Further working mode changes

[Anne van Kesteren]

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

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

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

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


-- 
https://annevankesteren.nl/

Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Michael A. Peters]

On 12/11/2017 04:30 AM, Jirka Kosek wrote:

On 11.12.2017 11:39, Christoph Päper wrote:

As with  and , HTML could also add  or something similar to 
embed MusicXML. Lyrics are a subset of musical notation and poems are, arguably, a special kind 
of lyrics (or the other way around).


This would require change to HTML parsing rules which ideally shoudn't
ever happen again.

Easier approach is to use XHTML syntax and simply embedded fragment of
specific XML vocabulary. It's pity that extensibility has been largely
thrown away when HTML5 was designed.


I always serve my pages as application/xhtml+xml except when an honest 
bot asks for the page (Twitter, some accessibility testers, Google Page 
Speed, all have trouble with real XML - often either screwing up with 
the self-closing script tags or parsing it correctly as XML but adding 
junk after the closing tag somewhere in their processing)


I've not tried as I don't think browsers would know what to do, but one 
should be able to add other XML namespaces to html5 served as proper 
XML, no?


That's how we had to to MathML circa 2000 before HTML5 (and then if I 
recall only Mozilla knew what to do with the MathML) - the same thing 
should work if browsers knew what to do with MusicXML or whatever.

Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Jirka Kosek]

On 11.12.2017 11:39, Christoph Päper wrote:
> As with  and , HTML could also add  or something similar to 
> embed MusicXML. Lyrics are a subset of musical notation and poems are, 
> arguably, a special kind of lyrics (or the other way around).

This would require change to HTML parsing rules which ideally shoudn't
ever happen again.

Easier approach is to use XHTML syntax and simply embedded fragment of
specific XML vocabulary. It's pity that extensibility has been largely
thrown away when HTML5 was designed.

BTW, MusicXML is really not appropriate for poems. There is existing
markup for poems in TEI: http://teibyexample.org/modules/TBED04v00.htm

Jirka

-- 
--
  Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
--
 Professional XML and Web consulting and training services
DocBook/DITA customization, custom XSLT/XSL-FO document processing
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--

Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Christoph Päper]

> "Tab Atkins Jr." :
> On Sun, Nov 26, 2017 at 8:59 AM, GevCbmlGM  wrote:
> >
> > Is there any recommend standard HTML tags for POEM and MUSIC LYRICS?
> 
> Poems and lyrics are, generally, just text that has significant
> line-breaks. Thus,  and are the correct markup for them.

As with  and , HTML could also add  or something similar to 
embed MusicXML. Lyrics are a subset of musical notation and poems are, 
arguably, a special kind of lyrics (or the other way around).

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Garrett Smith]

.
> 
>> On Fri, Dec 1, 2017 at 4:36 AM David Bruant  wrote:
>> 
>>> Le 28/11/2017 à 00:48, Jonathan Zuckerman a écrit :
>>> You’re probably aware there are libraries that offer functionality of
>> this
>>> sort (debounce and throttle in underscore/lodash is the one I’m most

Maybe there should be events for onscrollend and onresizeend. 

How that end is determined, e.g. via gestures, mouse, or keyboard shortcuts, 
can be spec’d and implementation details to be be obscured away by the browser. 

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Sylon Zero]

David,

To clarify your message: it sounds like it is primarily feedback to
Jonathan about the fact that a wide range of use cases and awareness of
options exist in the Web community at large, and also that some of the
existing options in the addEventListener parameters are useful even though
one may be able to handle some of those using custom code. Is that a fair
summary of your points?

I wanted to make sure I didn’t miss out on any feedback you were giving on
the proposal itself.

- Sai.

On Fri, Dec 1, 2017 at 4:36 AM David Bruant  wrote:

> Le 28/11/2017 à 00:48, Jonathan Zuckerman a écrit :
> > You’re probably aware there are libraries that offer functionality of
> this
> > sort (debounce and throttle in underscore/lodash is the one I’m most
> > familiar with) and the web community seems content to add a small
> > dependency when such functionality is required.
> With all due respect, i think it's dangerous to start a sentence by "the
> web community" given how broad and ever-changing this group of human
> beings is.
>
> For one data point, it's been 6 years that i regularly give advanced
> JavaScript trainings to people who are already JS practitionners and
> they don't know about the concept of event queue and barely about basic
> perf advices (reduce round trips to a minimum, minimize the size of
> what's sent, etc.). Debounce/throttling is further down the road.
>
> By the logic of "the web community seems content to add a small
> dependency", the 'once' option [1], probably shouldn't have seen the
> light given how easy it is to rewrite. Same for 'passive'. Same for
> Element.prototype.remove ("DOM4"). etc.
> I'm glad they exist though.
>
> David
>
> [1]
>
> https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
>
> > How would you convince
> > browser vendors to implement this?
> >
> >
> > On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:
> >
> >> *Core Problem Statement* Processor functions that subscribe to events
> via a
> >> topic string may need to be prioritized for processing based on the
> topic
> >> itself. Conversely, certain events may be more numerous but should not
> >> limit the ability of the JS environment to respond and process other
> >> events, that may be more critical to either the User Experience (UX) or
> >> integrity of the system (e.g. events that trigger saving data to a
> >> back-end).
> >>
> >> *Background Information* As Browser/CommonJS environments bring
> paradigms
> >> like UI event handling and back-end event handling into the same problem
> >> space, it is useful to apply common patterns used in Message-based
> >> Publish-Subscribe environments with message brokers, which is what the
> JS
> >> execution context often behaves as. The use case here is to ensure that
> one
> >> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t
> saturate
> >> or delay execution of other events (e.g. ‘dataAvailableForAutosave’)
> due to
> >> massive differences in event volume or conversely, expensive operations
> >> that block the execution thread in question.
> >>
> >> *Proposed Solution* Add metering options to the addEventListener
> >> *Options* configuration
> >> object. These options control how the JS execution environment controls
> the
> >> throttling/firing of event handler instances in response to events that
> >> match the topic string of the subscription created by addEventListener.
> >>
> >> Proposed options:
> >>
> >> - maxInstances [Number / Function] used to decide how many event
> >> listeners can be invoked before throttling occurs. Throttling does
> not
> >> lose
> >> events but simply queues them.
> >> - throttlingQueueLength [Number] used to maintain an in-memory
> queue of
> >> un-processed events per Topic string, after throttling kicks in.
> >> - throttlingQueuePolicy [String] Values could be exception - throws
> an
> >> exception when the queue length is exceeded, rolling - drops the
> oldest
> >> events and pushes newer ones into the queue, expand- allow the
> queue to
> >> expand to cover all events.
> >>
> >> *Additional Options* It might be even more useful if the options allowed
> >> targeting or creation of Web Workers (or Node child processes,
> depending on
> >> the execution context) based on the event handler configuration. This
> could
> >> potentially target CPU cores and/or O/S child processes / threads
> >> (depending on the O/S terminology for parallel execution).
> >>
> >> *Related Thread* The proposal identified in the link below (by Šime
> >> Vidas) could
> >> be part of this solution as it defines other metering options around
> >> debounce (which improves scale around event handling, which is in the
> same
> >> problem space) and handling throttling through frequency, which should
> be
> >> one of the alternatives in addition to my proposal above (as I believe
> they
> >> are orthogonal): 

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[David Bruant]

Le 28/11/2017 à 00:48, Jonathan Zuckerman a écrit :

You’re probably aware there are libraries that offer functionality of this
sort (debounce and throttle in underscore/lodash is the one I’m most
familiar with) and the web community seems content to add a small
dependency when such functionality is required.
With all due respect, i think it's dangerous to start a sentence by "the 
web community" given how broad and ever-changing this group of human 
beings is.


For one data point, it's been 6 years that i regularly give advanced 
JavaScript trainings to people who are already JS practitionners and 
they don't know about the concept of event queue and barely about basic 
perf advices (reduce round trips to a minimum, minimize the size of 
what's sent, etc.). Debounce/throttling is further down the road.


By the logic of "the web community seems content to add a small 
dependency", the 'once' option [1], probably shouldn't have seen the 
light given how easy it is to rewrite. Same for 'passive'. Same for 
Element.prototype.remove ("DOM4"). etc.

I'm glad they exist though.

David

[1] 
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener



How would you convince
browser vendors to implement this?


On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:


*Core Problem Statement* Processor functions that subscribe to events via a
topic string may need to be prioritized for processing based on the topic
itself. Conversely, certain events may be more numerous but should not
limit the ability of the JS environment to respond and process other
events, that may be more critical to either the User Experience (UX) or
integrity of the system (e.g. events that trigger saving data to a
back-end).

*Background Information* As Browser/CommonJS environments bring paradigms
like UI event handling and back-end event handling into the same problem
space, it is useful to apply common patterns used in Message-based
Publish-Subscribe environments with message brokers, which is what the JS
execution context often behaves as. The use case here is to ensure that one
kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
massive differences in event volume or conversely, expensive operations
that block the execution thread in question.

*Proposed Solution* Add metering options to the addEventListener
*Options* configuration
object. These options control how the JS execution environment controls the
throttling/firing of event handler instances in response to events that
match the topic string of the subscription created by addEventListener.

Proposed options:

- maxInstances [Number / Function] used to decide how many event
listeners can be invoked before throttling occurs. Throttling does not
lose
events but simply queues them.
- throttlingQueueLength [Number] used to maintain an in-memory queue of
un-processed events per Topic string, after throttling kicks in.
- throttlingQueuePolicy [String] Values could be exception - throws an
exception when the queue length is exceeded, rolling - drops the oldest
events and pushes newer ones into the queue, expand- allow the queue to
expand to cover all events.

*Additional Options* It might be even more useful if the options allowed
targeting or creation of Web Workers (or Node child processes, depending on
the execution context) based on the event handler configuration. This could
potentially target CPU cores and/or O/S child processes / threads
(depending on the O/S terminology for parallel execution).

*Related Thread* The proposal identified in the link below (by Šime
Vidas) could
be part of this solution as it defines other metering options around
debounce (which improves scale around event handling, which is in the same
problem space) and handling throttling through frequency, which should be
one of the alternatives in addition to my proposal above (as I believe they
are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
g-and-debouncing-to-addeventlisteneroptions/2436/19

Sai Prakash
@SylonZero

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Jonathan Zuckerman]

>From my own experience, only about half of the times I’ve required debounce
or throttle has been related to event handling, so if your proposal was
accepted I’d still need to include a library to satisfy the other scenarios.
On Tue, Nov 28, 2017 at 00:01 Sylon Zero  wrote:

> I think libraries having those functions emphasizes the point here, as
> that validates the existence and need for those patterns which then raises
> the requirement: should this be native to the browser?
>
> I believe the answer is yes, given how much work has already been put into
> standardizing the resource/computation model around the browser (web
> workers, local storage, etc) which is architecturally, IMHO, a related
> effort. Those capabilities come to life when there are smarter ways to
> utilize and route work to them through built-in features related to
> processing events/messages. In an effort to not create a science project
> out of some sort of top-down attack on this requirement, a simple
> middle-out approach with immediate results would be to extend the
> eventListener behavior that is prevalent in both browser and node.js
> scenarios.
>
> The case I am making first and foremost is that these recognizable
> patterns will be increasingly requisite (and not an after-thought, to be
> brought in via Underscore) in building web apps in the near term as web app
> complexity & use has increased dramatically with multiple cloud-scale
> offerings running in the SaaS space (think Netflix, LinkedIn, Facebook,
> Slack, etc) and more being built in various startups & emerging
> businesses. If the browser is to gain parity as an Application Platform
> allowing the development of web applications to rival native ones, then the
> ability to deal with volatile/durable messaging and events, storage and
> routing of work should be a core capability.
>
> *Broader implications:*
> If I may, let me add that I also think there is a growing confluence
> between the hybrid desktop app and browser-based SPAs (the Electron
> framework and its numerous successful projects like Atom, Slack, Visual
> Studio Code are great examples) and if the browser is to continue to evolve
> as a platform to encourage this trend (which is fabulous for the web
> community), then investments must be made to extend / normalize the browser
> standards in much the same way that the concept of a standardized
> Application Server helped standardize app architectures. This implies a
> future with registration of libraries/components (managed code), better
> local storage/caching options, improved integration with security contexts
> (per O/S), and likely much more. At least, I think it does :-).
>
>
> On Mon, Nov 27, 2017 at 6:48 PM, Jonathan Zuckerman  > wrote:
>
>> You’re probably aware there are libraries that offer functionality of
>> this sort (debounce and throttle in underscore/lodash is the one I’m most
>> familiar with) and the web community seems content to add a small
>> dependency when such functionality is required. How would you convince
>> browser vendors to implement this?
>> On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:
>>
>>> *Core Problem Statement* Processor functions that subscribe to events
>>> via a
>>> topic string may need to be prioritized for processing based on the topic
>>> itself. Conversely, certain events may be more numerous but should not
>>> limit the ability of the JS environment to respond and process other
>>> events, that may be more critical to either the User Experience (UX) or
>>> integrity of the system (e.g. events that trigger saving data to a
>>> back-end).
>>>
>>> *Background Information* As Browser/CommonJS environments bring paradigms
>>> like UI event handling and back-end event handling into the same problem
>>> space, it is useful to apply common patterns used in Message-based
>>> Publish-Subscribe environments with message brokers, which is what the JS
>>> execution context often behaves as. The use case here is to ensure that
>>> one
>>> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t
>>> saturate
>>> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due
>>> to
>>> massive differences in event volume or conversely, expensive operations
>>> that block the execution thread in question.
>>>
>>> *Proposed Solution* Add metering options to the addEventListener
>>> *Options* configuration
>>> object. These options control how the JS execution environment controls
>>> the
>>> throttling/firing of event handler instances in response to events that
>>> match the topic string of the subscription created by addEventListener.
>>>
>>> Proposed options:
>>>
>>>- maxInstances [Number / Function] used to decide how many event
>>>listeners can be invoked before throttling occurs. Throttling does
>>> not lose
>>>events but simply queues them.
>>>- throttlingQueueLength [Number] used to maintain an in-memory 

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Sylon Zero]

I think libraries having those functions emphasizes the point here, as that
validates the existence and need for those patterns which then raises the
requirement: should this be native to the browser?

I believe the answer is yes, given how much work has already been put into
standardizing the resource/computation model around the browser (web
workers, local storage, etc) which is architecturally, IMHO, a related
effort. Those capabilities come to life when there are smarter ways to
utilize and route work to them through built-in features related to
processing events/messages. In an effort to not create a science project
out of some sort of top-down attack on this requirement, a simple
middle-out approach with immediate results would be to extend the
eventListener behavior that is prevalent in both browser and node.js
scenarios.

The case I am making first and foremost is that these recognizable patterns
will be increasingly requisite (and not an after-thought, to be brought in
via Underscore) in building web apps in the near term as web app complexity
& use has increased dramatically with multiple cloud-scale offerings
running in the SaaS space (think Netflix, LinkedIn, Facebook, Slack, etc)
and more being built in various startups & emerging businesses. If the
browser is to gain parity as an Application Platform allowing the
development of web applications to rival native ones, then the ability to
deal with volatile/durable messaging and events, storage and routing of
work should be a core capability.

*Broader implications:*
If I may, let me add that I also think there is a growing confluence
between the hybrid desktop app and browser-based SPAs (the Electron
framework and its numerous successful projects like Atom, Slack, Visual
Studio Code are great examples) and if the browser is to continue to evolve
as a platform to encourage this trend (which is fabulous for the web
community), then investments must be made to extend / normalize the browser
standards in much the same way that the concept of a standardized
Application Server helped standardize app architectures. This implies a
future with registration of libraries/components (managed code), better
local storage/caching options, improved integration with security contexts
(per O/S), and likely much more. At least, I think it does :-).


On Mon, Nov 27, 2017 at 6:48 PM, Jonathan Zuckerman 
wrote:

> You’re probably aware there are libraries that offer functionality of this
> sort (debounce and throttle in underscore/lodash is the one I’m most
> familiar with) and the web community seems content to add a small
> dependency when such functionality is required. How would you convince
> browser vendors to implement this?
> On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:
>
>> *Core Problem Statement* Processor functions that subscribe to events via
>> a
>> topic string may need to be prioritized for processing based on the topic
>> itself. Conversely, certain events may be more numerous but should not
>> limit the ability of the JS environment to respond and process other
>> events, that may be more critical to either the User Experience (UX) or
>> integrity of the system (e.g. events that trigger saving data to a
>> back-end).
>>
>> *Background Information* As Browser/CommonJS environments bring paradigms
>> like UI event handling and back-end event handling into the same problem
>> space, it is useful to apply common patterns used in Message-based
>> Publish-Subscribe environments with message brokers, which is what the JS
>> execution context often behaves as. The use case here is to ensure that
>> one
>> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t
>> saturate
>> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due
>> to
>> massive differences in event volume or conversely, expensive operations
>> that block the execution thread in question.
>>
>> *Proposed Solution* Add metering options to the addEventListener
>> *Options* configuration
>> object. These options control how the JS execution environment controls
>> the
>> throttling/firing of event handler instances in response to events that
>> match the topic string of the subscription created by addEventListener.
>>
>> Proposed options:
>>
>>- maxInstances [Number / Function] used to decide how many event
>>listeners can be invoked before throttling occurs. Throttling does not
>> lose
>>events but simply queues them.
>>- throttlingQueueLength [Number] used to maintain an in-memory queue of
>>un-processed events per Topic string, after throttling kicks in.
>>- throttlingQueuePolicy [String] Values could be exception - throws an
>>exception when the queue length is exceeded, rolling - drops the oldest
>>events and pushes newer ones into the queue, expand- allow the queue to
>>expand to cover all events.
>>
>> *Additional Options* It might be even more useful if the options 

Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Jonathan Zuckerman]

You’re probably aware there are libraries that offer functionality of this
sort (debounce and throttle in underscore/lodash is the one I’m most
familiar with) and the web community seems content to add a small
dependency when such functionality is required. How would you convince
browser vendors to implement this?
On Mon, Nov 27, 2017 at 18:05 Sylon Zero  wrote:

> *Core Problem Statement* Processor functions that subscribe to events via a
> topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener
> *Options* configuration
> object. These options control how the JS execution environment controls the
> throttling/firing of event handler instances in response to events that
> match the topic string of the subscription created by addEventListener.
>
> Proposed options:
>
>- maxInstances [Number / Function] used to decide how many event
>listeners can be invoked before throttling occurs. Throttling does not
> lose
>events but simply queues them.
>- throttlingQueueLength [Number] used to maintain an in-memory queue of
>un-processed events per Topic string, after throttling kicks in.
>- throttlingQueuePolicy [String] Values could be exception - throws an
>exception when the queue length is exceeded, rolling - drops the oldest
>events and pushes newer ones into the queue, expand- allow the queue to
>expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime
> Vidas) could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>

[whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Sylon Zero]

*Core Problem Statement* Processor functions that subscribe to events via a
topic string may need to be prioritized for processing based on the topic
itself. Conversely, certain events may be more numerous but should not
limit the ability of the JS environment to respond and process other
events, that may be more critical to either the User Experience (UX) or
integrity of the system (e.g. events that trigger saving data to a
back-end).

*Background Information* As Browser/CommonJS environments bring paradigms
like UI event handling and back-end event handling into the same problem
space, it is useful to apply common patterns used in Message-based
Publish-Subscribe environments with message brokers, which is what the JS
execution context often behaves as. The use case here is to ensure that one
kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
massive differences in event volume or conversely, expensive operations
that block the execution thread in question.

*Proposed Solution* Add metering options to the addEventListener
*Options* configuration
object. These options control how the JS execution environment controls the
throttling/firing of event handler instances in response to events that
match the topic string of the subscription created by addEventListener.

Proposed options:

   - maxInstances [Number / Function] used to decide how many event
   listeners can be invoked before throttling occurs. Throttling does not lose
   events but simply queues them.
   - throttlingQueueLength [Number] used to maintain an in-memory queue of
   un-processed events per Topic string, after throttling kicks in.
   - throttlingQueuePolicy [String] Values could be exception - throws an
   exception when the queue length is exceeded, rolling - drops the oldest
   events and pushes newer ones into the queue, expand- allow the queue to
   expand to cover all events.

*Additional Options* It might be even more useful if the options allowed
targeting or creation of Web Workers (or Node child processes, depending on
the execution context) based on the event handler configuration. This could
potentially target CPU cores and/or O/S child processes / threads
(depending on the O/S terminology for parallel execution).

*Related Thread* The proposal identified in the link below (by Šime
Vidas) could
be part of this solution as it defines other metering options around
debounce (which improves scale around event handling, which is in the same
problem space) and handling throttling through frequency, which should be
one of the alternatives in addition to my proposal above (as I believe they
are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
g-and-debouncing-to-addeventlisteneroptions/2436/19

Sai Prakash
@SylonZero

Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

[Tab Atkins Jr.]

On Sun, Nov 26, 2017 at 8:59 AM, GevCbmlGM  wrote:
> Hi,
>
> Is there any recommend standard HTML tags for POEM and MUSIC LYRICS?
>
> I searched and did not see anyone talk about it.
> But I see different creative way people come up for POEM / STANZA / LINE
>
> 1.
>   
>
> 2.
>   
>
> 3.
>   
>
> 4.
>  then text with line brakes and proportional font using CSS styling.
>
> I wish it to be standardized, so if no recommendation exist, I suggest
> following tags.
>  - With left/right intend from margin, and zero top/bottom
> margin (almost  BLOCKQUOTE).
>  - With top/bottom margin, but zero left/right margin (similar to  
> ).
>  this is for LINE, single character tag name to replace use of BR.
> Content in tag should not word wrap, instead it should continue
> right side like contents in  tag.
>
> We also need a set of tags for MUSIC LYRICS, with VERSE, CHORUS,
> tag/attribute to mark repetition. As well as other tags/attributes
> which music community thinks will be needed.

Poems and lyrics are, generally, just text that has significant
line-breaks. Thus,  and  are the correct markup for them.

For poetry that plays around with spacing and alignment (and thus has
significant whitespace),  is the correct markup for it.

To add anything new to support these, head over to
 and run thru the
questionaire there; the bar for new additions to HTML is relatively
high. In particular, merely wanting to encode more semantics into a
document is often not worthwhile - in general, semantics are only
useful insofar as they help machines understand the document (so they
can help humans more effectively, such as screenreaders, search engine
spiders, etc.). You'll have to answer to why this level of additional
semantics for poetry is valuable in this way, and how it improves over
the current situation in tools that actually exist (or make a *very*
convincing argument that the current lack of semantics *prevents* a
useful tool from existing, and it's likely that the tool will develop
on its own after this is added).

~TJ

[whatwg] HTML tags for POEM and MUSIC LYRICS

[GevCbmlGM]

Hi,

Is there any recommend standard HTML tags for POEM and MUSIC LYRICS?

I searched and did not see anyone talk about it.
But I see different creative way people come up for POEM / STANZA / LINE

1.
  

2.
  

3.
  

4.
 then text with line brakes and proportional font using CSS styling.

I wish it to be standardized, so if no recommendation exist, I suggest
following tags.
 - With left/right intend from margin, and zero top/bottom
margin (almost  BLOCKQUOTE).
 - With top/bottom margin, but zero left/right margin (similar to  ).
 this is for LINE, single character tag name to replace use of BR.
Content in tag should not word wrap, instead it should continue
right side like contents in  tag.

We also need a set of tags for MUSIC LYRICS, with VERSE, CHORUS,
tag/attribute to mark repetition. As well as other tags/attributes
which music community thinks will be needed.


Cheers
Gev C

[bijugc]

(further research https://en.wikipedia.org/wiki/Song_structure )

Re: [whatwg] How to handle Session Expiry in ServiceWorker

[Richard Maher]

It seems there has been discussion on this before. Please see GitHub




I think that background re-authenticating should be infrequent enough that
a notification of the sign-in or failure is an appropriate and
user-friendly solution.

Please comment over there if you have any ideas!

[whatwg] How to handle Session Expiry in ServiceWorker

[Richard Maher]

If a Fetch in my ServiceWorker receives a 401 from the server how do I
re-authenticate with the server if I have no focused or foregrounded client?

NB: I'm talking about POST requests updating the server and not just
reading from cache until the network is back.

Bring the client back into focus? Scary for user with no action causing
that reaction and they may not be there to login again anyway.

What does Background-Synch do if it gets a 401?

If navigator.credentials was surfaced in a ServiceWorker that would be
enough!

Sessions that never expire?

What are other people doing?

Yet again I'm banned from W3C/IETF Github :-(

If someone could add the following to ServiceWorker issues
 that would help: - Please
see Use-Case


If a User Session has expired a ServiceWorker currently has no mechanisms
available to re-authenticate with the server as there is no heuristic
mechanism available for determining credentials.

If the credentials.get() was available then re-authentication could take
place transparently. If federated (say Google) then if the user had logged
out then that state would be honoured.

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Was just informed that using aria-hidden solves the problem of content 
being there that shouldn't be seen in a screen reader until agreed, so 
that issue has a solution too.


I guess none of this really is meaningful to this list - sorry for the 
noise.


On 11/12/2017 04:18 AM, Michael A. Peters wrote:

Yes but since I always have the div first in HTML the user is likely to
always be aware of it, so skipping it in a screen reader is really
little different than just pressing the agree button - they have been
informed of the type of content.

On 11/12/2017 04:09 AM, Johannes Spangenberg wrote:

There is another problem with Modals on webpages. When there is a modal
created through HTML and CSS, the user can still select items in the
background by pressing tab. It seems that there is no good solution to
prevent it.


Am 12.11.2017 um 09:59 schrieb Michael A. Peters:

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role



On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters

wrote:


On webites that either are age restricted and/or have content that
may be
offensive to some people, often (but not as often as I'd like) there
is a
warning splashscreen that the server puts in the page if the user
has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or
whatever,
then it does an ajax call to lett the server the user has verified
they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would
have
the same properties as a div only it would have semantic meaning so
that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it
from
complementary which is what I currently use for it (I would use
banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems
reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other
semantic
tag.

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Yes but since I always have the div first in HTML the user is likely to 
always be aware of it, so skipping it in a screen reader is really 
little different than just pressing the agree button - they have been 
informed of the type of content.


On 11/12/2017 04:09 AM, Johannes Spangenberg wrote:

There is another problem with Modals on webpages. When there is a modal
created through HTML and CSS, the user can still select items in the
background by pressing tab. It seems that there is no good solution to
prevent it.


Am 12.11.2017 um 09:59 schrieb Michael A. Peters:

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role


On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters

wrote:


On webites that either are age restricted and/or have content that
may be
offensive to some people, often (but not as often as I'd like) there
is a
warning splashscreen that the server puts in the page if the user
has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or
whatever,
then it does an ajax call to lett the server the user has verified they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would
have
the same properties as a div only it would have semantic meaning so
that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it
from
complementary which is what I currently use for it (I would use
banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems
reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other
semantic
tag.

Re: [whatwg] new tag and possible new aria role

[Johannes Spangenberg]

There is another problem with Modals on webpages. When there is a modal 
created through HTML and CSS, the user can still select items in the 
background by pressing tab. It seems that there is no good solution to 
prevent it.


Am 12.11.2017 um 09:59 schrieb Michael A. Peters:
> Thank you! That does seem like it is exactly what I need.
>
> On 11/12/2017 12:11 AM, Yay295 wrote:
>> I think the alertdialog role fits here.
>> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role
>>  
>>
>>
>> On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters 
>> 
>> wrote:
>>
>>> On webites that either are age restricted and/or have content that 
>>> may be
>>> offensive to some people, often (but not as often as I'd like) there 
>>> is a
>>> warning splashscreen that the server puts in the page if the user 
>>> has not
>>> already agreed to see such content.
>>>
>>> One way to do this is with a div that has absolute positioning and a
>>> z-index that covers the content until the user clicks enter or 
>>> whatever,
>>> then it does an ajax call to lett the server the user has verified they
>>> want to see the content and removes the div.
>>>
>>> I would suggest a tagName "splashscreen" for this purpose. It would 
>>> have
>>> the same properties as a div only it would have semantic meaning so 
>>> that
>>> people using screen readers would know it is important.
>>>
>>> An aria landmark of splashscreen would also properly distinguish it 
>>> from
>>> complementary which is what I currently use for it (I would use 
>>> banner but
>>> only one banner landmark per page is allowed).
>>>
>>> Just a thought, I won't defend the thought but if it seems 
>>> reasonable to
>>> the powers that be, I think it is worth it.
>>>
>>> These splash screens do serve a different purpose than any other 
>>> semantic
>>> tag.
>>>
>

Re: [whatwg] new tag and possible new aria role

[Michael A. Peters]

Thank you! That does seem like it is exactly what I need.

On 11/12/2017 12:11 AM, Yay295 wrote:

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role

On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters 
wrote:


On webites that either are age restricted and/or have content that may be
offensive to some people, often (but not as often as I'd like) there is a
warning splashscreen that the server puts in the page if the user has not
already agreed to see such content.

One way to do this is with a div that has absolute positioning and a
z-index that covers the content until the user clicks enter or whatever,
then it does an ajax call to lett the server the user has verified they
want to see the content and removes the div.

I would suggest a tagName "splashscreen" for this purpose. It would have
the same properties as a div only it would have semantic meaning so that
people using screen readers would know it is important.

An aria landmark of splashscreen would also properly distinguish it from
complementary which is what I currently use for it (I would use banner but
only one banner landmark per page is allowed).

Just a thought, I won't defend the thought but if it seems reasonable to
the powers that be, I think it is worth it.

These splash screens do serve a different purpose than any other semantic
tag.

Re: [whatwg] new tag and possible new aria role

[Yay295]

I think the alertdialog role fits here.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role

On Sun, Nov 12, 2017 at 1:03 AM, Michael A. Peters 
wrote:

> On webites that either are age restricted and/or have content that may be
> offensive to some people, often (but not as often as I'd like) there is a
> warning splashscreen that the server puts in the page if the user has not
> already agreed to see such content.
>
> One way to do this is with a div that has absolute positioning and a
> z-index that covers the content until the user clicks enter or whatever,
> then it does an ajax call to lett the server the user has verified they
> want to see the content and removes the div.
>
> I would suggest a tagName "splashscreen" for this purpose. It would have
> the same properties as a div only it would have semantic meaning so that
> people using screen readers would know it is important.
>
> An aria landmark of splashscreen would also properly distinguish it from
> complementary which is what I currently use for it (I would use banner but
> only one banner landmark per page is allowed).
>
> Just a thought, I won't defend the thought but if it seems reasonable to
> the powers that be, I think it is worth it.
>
> These splash screens do serve a different purpose than any other semantic
> tag.
>

[whatwg] new tag and possible new aria role

[Michael A. Peters]

On webites that either are age restricted and/or have content that may 
be offensive to some people, often (but not as often as I'd like) there 
is a warning splashscreen that the server puts in the page if the user 
has not already agreed to see such content.


One way to do this is with a div that has absolute positioning and a 
z-index that covers the content until the user clicks enter or whatever, 
then it does an ajax call to lett the server the user has verified they 
want to see the content and removes the div.


I would suggest a tagName "splashscreen" for this purpose. It would have 
the same properties as a div only it would have semantic meaning so that 
people using screen readers would know it is important.


An aria landmark of splashscreen would also properly distinguish it from 
complementary which is what I currently use for it (I would use banner 
but only one banner landmark per page is allowed).


Just a thought, I won't defend the thought but if it seems reasonable to 
the powers that be, I think it is worth it.


These splash screens do serve a different purpose than any other 
semantic tag.

[whatwg] unsubscribe

[Sales@EssayAuto]

On Tue, Oct 31, 2017 at 2:23 PM, Regis Kuckaertz <
regis.kuckae...@theguardian.com> wrote:

> Hello,
>
> The other day I came across the following behaviour and would like to ask
> your opinion on the matter. It is not uncommon to find forms such as:
>
> 
>   
>   Add to
> favourites
>   Duplicate
>   Delete
> 
>
> When a user presses one of these buttons, the UA picks the corresponding
> value and streamlines it in the form data, as expected. Yet if you try to
> catch the submit event in JavaScript, you won't be able to catch that
> value:
>
> formElement.onsubmit = (evt) => {
>   evt.preventDefault();
>   const button = evt.target.elements.namedItem('action');
>   const value = button.value
>   console.log(value);
>   // logs the empty string
> }
>
> The reason for that is HTMLFormCollection.namedItem(name) returns a
> RadioNodeList. Here is the relevant part of the standard: "[if there is
> more than one node with id/name 'name',] create a new RadioNodeList object
> representing a live view of the HTMLFormControlsCollection object, further
> filtered so that the only nodes in the RadioNodeList object are those that
> have either an id attribute or a name attribute equal to name."
>
> RadioNodeList is a NodeList where the value property, on getting, yields
> the value of the first  element in tree order which
> checkedness is true, or the empty string. In the above case, it is obvious
> that none of the buttons match that description.
>
> There are two solutions that I know of: either give each button a unique
> name (but then the value becomes useless) or listen for
> click/keypress/touch events on these buttons; but somehow none of these
> solutions seem elegant to me.
>
> Here is my question: if the UA handles this situation without a glitch,
> wouldn't you expect the corresponding DOM API to expose the same behaviour?
> It is true that, from the name of it, I wouldn't have expected it to work
> with anything but radio buttons, but then I wonder if this use case doesn't
> warrant either the creation of a similar ButtonNodeList, or a relaxation of
> the rule for getting the value.
>
> Best regards,
> Regis
>
> --
>
> --
> This e-mail and all attachments are confidential and may also be
> privileged. If you are not the named recipient, please notify the sender
> and delete the e-mail and all attachments immediately. Do not disclose the
> contents to another person. You may not use the information for any
> purpose, or store, or copy, it in any way.  Guardian News & Media Limited
> is not liable for any computer viruses or other material transmitted with
> or as part of this e-mail. You should employ virus checking software.
>
> Guardian News & Media Limited is a member of Guardian Media Group plc.
> Registered
> Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.
> Registered
> in England Number 908396
>
>
>

Re: [whatwg] RadioNodeList and buttons

[Régis Kuckaertz]

Hi Boris - That's awesome, thank you.

On Fri, Nov 3, 2017 at 6:23 PM Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 10/31/17 10:56 AM, Regis Kuckaertz wrote:
> > Indeed I find your idea more appealing and semantically clearer.
>
> OK, good.  Since it's not just me, I filed
> https://github.com/whatwg/html/issues/3195 on this.
>
> -Boris
>

Re: [whatwg] RadioNodeList and buttons

[Boris Zbarsky]

On 10/31/17 10:56 AM, Regis Kuckaertz wrote:

Indeed I find your idea more appealing and semantically clearer.


OK, good.  Since it's not just me, I filed 
https://github.com/whatwg/html/issues/3195 on this.


-Boris

Re: [whatwg] RadioNodeList and buttons

[Regis Kuckaertz]

Thanks for your question. Phrased like that, it becomes clear to me that I
did not think enough about how the value would be computed in the case of a
set of buttons. There is no "checkedness" in buttons, not that I know of.

Indeed I find your idea more appealing and semantically clearer. When I
wrote the example, I thought the name attribute on buttons was redundant
with the type attribute.

On Tue, 31 Oct 2017 at 14:23 Boris Zbarsky  wrote:

> On 10/31/17 6:23 AM, Regis Kuckaertz wrote:
> > formElement.onsubmit = (evt) => {
> >evt.preventDefault();
> >const button = evt.target.elements.namedItem('action');
> >const value = button.value
>
> If this returned buttons, which button would you expect it to return in
> various situations and why?
>
> > Here is my question: if the UA handles this situation without a glitch,
> > wouldn't you expect the corresponding DOM API to expose the same
> behaviour?
>
> I just checked one UA (Firefox), and the way it handles this situation
> is that it stores the "submitter" (in the sense of the argument to
> ) on the
> "submit" event itself.  Exposing it as a property on that event would
> make a lot of sense to me.
>
> -Boris
>

-- 

--
This e-mail and all attachments are confidential and may also be 
privileged. If you are not the named recipient, please notify the sender 
and delete the e-mail and all attachments immediately. Do not disclose the 
contents to another person. You may not use the information for any 
purpose, or store, or copy, it in any way.  Guardian News & Media Limited 
is not liable for any computer viruses or other material transmitted with 
or as part of this e-mail. You should employ virus checking software.
 
Guardian News & Media Limited is a member of Guardian Media Group plc. 
Registered 
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered 
in England Number 908396

Re: [whatwg] RadioNodeList and buttons

[Boris Zbarsky]

On 10/31/17 6:23 AM, Regis Kuckaertz wrote:

formElement.onsubmit = (evt) => {
   evt.preventDefault();
   const button = evt.target.elements.namedItem('action');
   const value = button.value


If this returned buttons, which button would you expect it to return in 
various situations and why?



Here is my question: if the UA handles this situation without a glitch,
wouldn't you expect the corresponding DOM API to expose the same behaviour?


I just checked one UA (Firefox), and the way it handles this situation 
is that it stores the "submitter" (in the sense of the argument to 
) on the 
"submit" event itself.  Exposing it as a property on that event would 
make a lot of sense to me.


-Boris

[whatwg] RadioNodeList and buttons

[Regis Kuckaertz]

Hello,

The other day I came across the following behaviour and would like to ask
your opinion on the matter. It is not uncommon to find forms such as:


  
  Add to
favourites
  Duplicate
  Delete


When a user presses one of these buttons, the UA picks the corresponding
value and streamlines it in the form data, as expected. Yet if you try to
catch the submit event in JavaScript, you won't be able to catch that value:

formElement.onsubmit = (evt) => {
  evt.preventDefault();
  const button = evt.target.elements.namedItem('action');
  const value = button.value
  console.log(value);
  // logs the empty string
}

The reason for that is HTMLFormCollection.namedItem(name) returns a
RadioNodeList. Here is the relevant part of the standard: "[if there is
more than one node with id/name 'name',] create a new RadioNodeList object
representing a live view of the HTMLFormControlsCollection object, further
filtered so that the only nodes in the RadioNodeList object are those that
have either an id attribute or a name attribute equal to name."

RadioNodeList is a NodeList where the value property, on getting, yields
the value of the first  element in tree order which
checkedness is true, or the empty string. In the above case, it is obvious
that none of the buttons match that description.

There are two solutions that I know of: either give each button a unique
name (but then the value becomes useless) or listen for
click/keypress/touch events on these buttons; but somehow none of these
solutions seem elegant to me.

Here is my question: if the UA handles this situation without a glitch,
wouldn't you expect the corresponding DOM API to expose the same behaviour?
It is true that, from the name of it, I wouldn't have expected it to work
with anything but radio buttons, but then I wonder if this use case doesn't
warrant either the creation of a similar ButtonNodeList, or a relaxation of
the rule for getting the value.

Best regards,
Regis

-- 

--
This e-mail and all attachments are confidential and may also be 
privileged. If you are not the named recipient, please notify the sender 
and delete the e-mail and all attachments immediately. Do not disclose the 
contents to another person. You may not use the information for any 
purpose, or store, or copy, it in any way.  Guardian News & Media Limited 
is not liable for any computer viruses or other material transmitted with 
or as part of this e-mail. You should employ virus checking software.
 
Guardian News & Media Limited is a member of Guardian Media Group plc. 
Registered 
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered 
in England Number 908396

Re: [whatwg] JavaScript function for closing tags

[Silvia Pfeiffer]

We could specify that WebVTT cues of type metadata should contain valid
JSON - that would make sense to me.

Cues of type captions or subtitles stupid get parsed dune by the addCue()
function of the texttrack API - but not all browsers implement this yet.
Would be worth registering bugs on browsers.

Cheers,
Silvia.

Best Regards,
Silvia.

On 18 Oct. 2017 2:51 am, "Michael A. Peters"  wrote:

> On 10/16/2017 10:08 AM, Roger Hågensen wrote:
>
>> On 2017-10-14 10:13, Michael A. Peters wrote:
>>
>>> I use TextTrack API but it's documention does not specify that it
>>> closes open tags within a cue, in fact I'm fairly certain it doesn't
>>> because some people use it for json and other related none tag related
>>> content.
>>>
>> Looking at https://www.html5rocks.com/en/tutorials/track/basics/
>> it seems JSON can be used, no idea if content type is different or not
>> for that.
>>
>> Some errors using the tracks in XML were solved by the innerHTML trick
>>> where I create a separate html document, append the cue, and then grab
>>> the innerHTML but that doesn't always work to close tags when html
>>> entities are part of the cue string.
>>>
>>
>> Mixing XML and HTML is not a good idea. Would it not be easier to have
>> the server send out proper XML instead of hTML? Valid XML is also valid
>> HTML (the reverse is not always true).
>>
>
> I agree, but what I was using an html document for - when using JS
> innerHTML it has closing tags so the only issue would be tags that html
> itself does not close (e.g. br) but those are not applicable with a WebVTT
> cue - which is only suppose to support a very small number of tags, all
> which have closing tags.
>
> The problem is WebVTT does not require tags be closed in a cue, e.g.
>
> 04:05.000 --> 04:07.250
> This is a cue.
>
> That's allowed in WebVTT
>
> I convert c.foo into
>
> This is a cue.
>
> and when I add that to the html document and use innerHTML it then has the
> closing  on it.
>
> While it seems to work with some html entities, it breaks with others like
> 
>
> So for now I have to just make sure all my WebVTT are closed and not use
> the hack that adds closing tags - but since WebVTT cues do not have to have
> closing tags, but the cues need to work in XML documents, a built-in parser
> in JS that can add missing closing tags I think would be a good thing.
>
>
> And if XML and HTML is giving you issues then use JSON instead.
>> I did not see JSON mentioned in the W3C spec though.
>>
>
> I think the JSON in WebVTT cues is not spec but some are using it.
>
> Basically the textrack API seems to allow almost any string, it really has
> to as WebVTT is not static and the spec changes. I wouldn't mind JSON being
> added to WebVTT as it would be a handy way to encode metadata about the
> media but that's another topic.
>
> A built in JS HTML parser may also be of benefit in preventing code
> injection, e.g. stripping out tags from a WebVTT cue that a website does
> not allow.
>
> The TextTrack API doesn't filter out things like script or other tags that
> aren't part of WebVTT which means any site that allows users to upload
> WebVTT files is creating a potential code injection vulnerability.
>
> Server-side code should filter it on upload, but it would be nice to
> *someday* be able to pass a string through a native JS filter much the same
> way we can with htmltidy server-side and remove all but white-listed tags
> and attributes and get back a cleaned string with all tags closed.
>
> It looks like Google has a library that does that but it isn't intended
> for client-side JS and may not be fast enough for things like phones to
> process time-sensitive cues (I don't know).
>
> I might be wrong but it looked like the google library I found was
> intended for server-side Node.js use.
>
>

Re: [whatwg] JavaScript function for closing tags

[Michael A. Peters]

On 10/16/2017 10:08 AM, Roger Hågensen wrote:

On 2017-10-14 10:13, Michael A. Peters wrote:

I use TextTrack API but it's documention does not specify that it
closes open tags within a cue, in fact I'm fairly certain it doesn't
because some people use it for json and other related none tag related
content.

Looking at https://www.html5rocks.com/en/tutorials/track/basics/
it seems JSON can be used, no idea if content type is different or not
for that.


Some errors using the tracks in XML were solved by the innerHTML trick
where I create a separate html document, append the cue, and then grab
the innerHTML but that doesn't always work to close tags when html
entities are part of the cue string.


Mixing XML and HTML is not a good idea. Would it not be easier to have
the server send out proper XML instead of hTML? Valid XML is also valid
HTML (the reverse is not always true).


I agree, but what I was using an html document for - when using JS 
innerHTML it has closing tags so the only issue would be tags that html 
itself does not close (e.g. br) but those are not applicable with a 
WebVTT cue - which is only suppose to support a very small number of 
tags, all which have closing tags.


The problem is WebVTT does not require tags be closed in a cue, e.g.

04:05.000 --> 04:07.250
This is a cue.

That's allowed in WebVTT

I convert c.foo into

This is a cue.

and when I add that to the html document and use innerHTML it then has 
the closing  on it.


While it seems to work with some html entities, it breaks with others 
like 


So for now I have to just make sure all my WebVTT are closed and not use 
the hack that adds closing tags - but since WebVTT cues do not have to 
have closing tags, but the cues need to work in XML documents, a 
built-in parser in JS that can add missing closing tags I think would be 
a good thing.




And if XML and HTML is giving you issues then use JSON instead.
I did not see JSON mentioned in the W3C spec though.


I think the JSON in WebVTT cues is not spec but some are using it.

Basically the textrack API seems to allow almost any string, it really 
has to as WebVTT is not static and the spec changes. I wouldn't mind 
JSON being added to WebVTT as it would be a handy way to encode metadata 
about the media but that's another topic.


A built in JS HTML parser may also be of benefit in preventing code 
injection, e.g. stripping out tags from a WebVTT cue that a website does 
not allow.


The TextTrack API doesn't filter out things like script or other tags 
that aren't part of WebVTT which means any site that allows users to 
upload WebVTT files is creating a potential code injection vulnerability.


Server-side code should filter it on upload, but it would be nice to 
*someday* be able to pass a string through a native JS filter much the 
same way we can with htmltidy server-side and remove all but 
white-listed tags and attributes and get back a cleaned string with all 
tags closed.


It looks like Google has a library that does that but it isn't intended 
for client-side JS and may not be fast enough for things like phones to 
process time-sensitive cues (I don't know).


I might be wrong but it looked like the google library I found was 
intended for server-side Node.js use.

[whatwg] Max-bandwidth (was Re: HTML : FEATURE SUGGESTION)

[Roger Hågensen]

On 2017-10-14 17:03, Uday Kandpal wrote:

may suggest you to kindly bring a new feature like unique resolution to be
set for all the video being loaded on demand to lowest possible resolution
so that unnecessary advertisement and videos do not consume the space
irrespective of any adware remover or ad blocker.


I'm not sure if having web specification dictate artificial resolution 
or bandwidth limitations is a good idea.


Also, browser will/can negotiate with the server. Either through the 
server starting "low" then increasing bandwith/resolution until freame 
start to drop.


Or through the use of alternative image resolutions in web pages


Also kindly bring in a button for the user to change the multimedia
resolution (image/video/applet/flash and other plugins) dynamically the
same way Youtube provides for videos. It may require a change in the
protocol for servers to convert the image to low resolutions before
sending, but it can be reduced to the scope of HTML processiong or xml
processing engine.


This can be done today through cookies or localStorage.



I have heard that the android developers were saving their multimedia
resource details in the XML Resource files.


The Android browser or video app developers?


One part of your suggestion do have merit though which I'll elaborate 
on. Upon connection a browser could pass along a bandwidth hint to the 
server.

Max-bandwidth: 800

Which would indicate that the browser desires the server to not send 
more than 8mbit per second to the browser.
Such a max may or may not be the max of the line of the user, in some 
cases a user may want to ensure that they have 2mbit free on a 10mbit 
line and thus bandwidth limit video/datatransfer to 8mbit.


It could then be up to the browser UI/user settings if this limit is per 
server or global for the browser, if global then the browser could halv 
that 8mbit into 4mbit and 4mbit for the two sites. Or perhaps 6mbit for 
video and 2mbit for non-video.


I'm not aware of any desktop browsers that have such features, I'm 
uncertain about mobile browsers though.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] JavaScript function for closing tags

[Roger Hågensen]

On 2017-10-14 10:13, Michael A. Peters wrote:
I use TextTrack API but it's documention does not specify that it closes 
open tags within a cue, in fact I'm fairly certain it doesn't because 
some people use it for json and other related none tag related content.

Looking at https://www.html5rocks.com/en/tutorials/track/basics/
it seems JSON can be used, no idea if content type is different or not 
for that.


Some errors using the tracks in XML were solved by the innerHTML trick 
where I create a separate html document, append the cue, and then grab 
the innerHTML but that doesn't always work to close tags when html 
entities are part of the cue string.


Mixing XML and HTML is not a good idea. Would it not be easier to have 
the server send out proper XML instead of hTML? Valid XML is also valid 
HTML (the reverse is not always true).

And if XML and HTML is giving you issues then use JSON instead.
I did not see JSON mentioned in the W3C spec though.


There does not seem to be a JavaScript API for closing open tags.

This is problematic when dealing with WebVTT which does not require 
tags be

closed.

Where it is the biggest problem is when the document is being served as
XML+XHTML


If a XML document is being served with unclosed tags then it's not valid 
XML, so it's no wonder if that then causes issues.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

[whatwg] HTML : FEATURE SUGGESTION

[Uday Kandpal]

hi,

As an Internet subscriber, and HTML content user, *kindly grant me your
precious time* for a suggestion that is very valuable for the future of the
dynamic multimedia content on the internet.

As you might have information about the video tag and multimedia, various
video database agencies including YouTube provide options to change the
video resolution ranging from 144p, 240p, 340p, 380p, 720p, 1080p, 1980p or
SD versions and HD versions, this is very useful for the user to be saved
for every video he browses on the internet, as well all the multimedia
content ranging from image to an applet/servlet. SO to exploit this fact, I
may suggest you to kindly bring a new feature like unique resolution to be
set for all the video being loaded on demand to lowest possible resolution
so that unnecessary advertisement and videos do not consume the space
irrespective of any adware remover or ad blocker.

Also kindly bring in a button for the user to change the multimedia
resolution (image/video/applet/flash and other plugins) dynamically the
same way Youtube provides for videos. It may require a change in the
protocol for servers to convert the image to low resolutions before
sending, but it can be reduced to the scope of HTML processiong or xml
processing engine.

I have heard that the android developers were saving their multimedia
resource details in the XML Resource files.

BEST OF LUCK

Thanks and Regards
Udaysagar Kandpal
Indian developer
(Past Employee: Adobe and IBM)

Re: [whatwg] JavaScript function for closing tags

[Michael A. Peters]

I use TextTrack API but it's documention does not specify that it closes 
open tags within a cue, in fact I'm fairly certain it doesn't because 
some people use it for json and other related none tag related content.


Some errors using the tracks in XML were solved by the innerHTML trick 
where I create a separate html document, append the cue, and then grab 
the innerHTML but that doesn't always work to close tags when html 
entities are part of the cue string.


I use JS regex to turn  into  and  
into  and just jQuery .append() to place 
the cue in a div for captions/subtitles since browser standard html5 
audio players have zero support for captions by themselves, and the 
jQuery .append() is what needs closing tags in XML or it understandably 
completely fails.


Also using it for chapters which don't appear to be supported in either 
browser standard audio or video players.


On 10/14/2017 12:46 AM, Silvia Pfeiffer wrote:

Hi Michael,

It seems to me that the TextTrack API is made for this use case.
Why does it not work for you?

Cheers,
Silvia.


On Sat, Oct 14, 2017 at 4:36 PM, Michael A. Peters
 wrote:

There does not seem to be a JavaScript API for closing open tags.

This is problematic when dealing with WebVTT which does not require tags be
closed.

Where it is the biggest problem is when the document is being served as
XML+XHTML

I tried the following hack which seemed to be working:

cleandoc = document.implementation.createHTMLDocument("FuBar");
cleanbody = document.createElementNS("http://www.w3.org/1999/xhtml;,
"body");
cleandoc.documentElement.appendChild(cleanbody);


Then I could do the following when with a WebVTT cue:

cleanbody.innerHTML = string;
return (cleanbody.innerHTML);

That *mostly* works but seems to sometimes fail when string contains
entities, such as 

What happens is it returns an empty string.

Given that WebVTT is part of HTML5 and browser native html5 audio players
don't support caption tracks forcing us to write our own implementations if
we want captions with audio, it sure would be nice if there was a pure
JavaScript way to just add closing tags to a string because there is never a
guarantee valid WebVTT cue has closed tags which are required for XHTML sent
as XML.

Seems to me that a JS native function to add missing closing tags would have
more application than just WebVTT cues.

I looked for a jQuery filter that does it, but could not find one.

It also could be of benefit in emulating document.write() as many of
Google's tools *still* require document.write() despite the issues with
document.write() and XML having been known for 15+ years now.

Any chance of getting a parser into JavaScript that at least would be
capable of closing open tags in a string passed to it?

Re: [whatwg] JavaScript function for closing tags

[Silvia Pfeiffer]

Hi Michael,

It seems to me that the TextTrack API is made for this use case.
Why does it not work for you?

Cheers,
Silvia.


On Sat, Oct 14, 2017 at 4:36 PM, Michael A. Peters
 wrote:
> There does not seem to be a JavaScript API for closing open tags.
>
> This is problematic when dealing with WebVTT which does not require tags be
> closed.
>
> Where it is the biggest problem is when the document is being served as
> XML+XHTML
>
> I tried the following hack which seemed to be working:
>
> cleandoc = document.implementation.createHTMLDocument("FuBar");
> cleanbody = document.createElementNS("http://www.w3.org/1999/xhtml;,
> "body");
> cleandoc.documentElement.appendChild(cleanbody);
>
>
> Then I could do the following when with a WebVTT cue:
>
> cleanbody.innerHTML = string;
> return (cleanbody.innerHTML);
>
> That *mostly* works but seems to sometimes fail when string contains
> entities, such as 
>
> What happens is it returns an empty string.
>
> Given that WebVTT is part of HTML5 and browser native html5 audio players
> don't support caption tracks forcing us to write our own implementations if
> we want captions with audio, it sure would be nice if there was a pure
> JavaScript way to just add closing tags to a string because there is never a
> guarantee valid WebVTT cue has closed tags which are required for XHTML sent
> as XML.
>
> Seems to me that a JS native function to add missing closing tags would have
> more application than just WebVTT cues.
>
> I looked for a jQuery filter that does it, but could not find one.
>
> It also could be of benefit in emulating document.write() as many of
> Google's tools *still* require document.write() despite the issues with
> document.write() and XML having been known for 15+ years now.
>
> Any chance of getting a parser into JavaScript that at least would be
> capable of closing open tags in a string passed to it?

[whatwg] JavaScript function for closing tags

[Michael A. Peters]

There does not seem to be a JavaScript API for closing open tags.

This is problematic when dealing with WebVTT which does not require tags 
be closed.


Where it is the biggest problem is when the document is being served as 
XML+XHTML


I tried the following hack which seemed to be working:

cleandoc = document.implementation.createHTMLDocument("FuBar");
cleanbody = document.createElementNS("http://www.w3.org/1999/xhtml;, 
"body");

cleandoc.documentElement.appendChild(cleanbody);


Then I could do the following when with a WebVTT cue:

cleanbody.innerHTML = string;
return (cleanbody.innerHTML);

That *mostly* works but seems to sometimes fail when string contains 
entities, such as 


What happens is it returns an empty string.

Given that WebVTT is part of HTML5 and browser native html5 audio 
players don't support caption tracks forcing us to write our own 
implementations if we want captions with audio, it sure would be nice if 
there was a pure JavaScript way to just add closing tags to a string 
because there is never a guarantee valid WebVTT cue has closed tags 
which are required for XHTML sent as XML.


Seems to me that a JS native function to add missing closing tags would 
have more application than just WebVTT cues.


I looked for a jQuery filter that does it, but could not find one.

It also could be of benefit in emulating document.write() as many of 
Google's tools *still* require document.write() despite the issues with 
document.write() and XML having been known for 15+ years now.


Any chance of getting a parser into JavaScript that at least would be 
capable of closing open tags in a string passed to it?

Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

On 10/06/2017 08:44 AM, Léonie Watson wrote:


On 06/10/2017 11:26, Michael A. Peters wrote:

Nope, no problem at all. That looks like a simple solution I did not
find. Thank you.


Note that you need to provide an explicit role on the span if you use
aria-label to provide its accessible name.


I assume if I instead put the aria-label on the button rather than span 
that contains the pictograph, that would work too without needing a role 
since it is an actual button.

Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

Nope, no problem at all. That looks like a simple solution I did not 
find. Thank you.


On 10/06/2017 08:23 AM, Jonathan Garbee wrote:

Is there a problem with using aria-label
<https://www.w3.org/TR/wai-aria/states_and_properties#aria-label> for
this use case? It seems like this should do exactly what you're asking
for in the given scenario.

On Fri, Oct 6, 2017 at 11:15 AM, Michael A. Peters
<mpet...@domblogger.net <mailto:mpet...@domblogger.net>> wrote:

With images, the alt attribute can and should be used to give a
description of an image for users who can not see the image.

With text, some glyphs are pictographs that have a meaning. For
example, U+1F502 is a pictograph indicating single loop, but it is
meaningless if you can not see it.

Even if screen readers can specify the codepoint and/or map the
codepoint to a description (do they?) sometimes fonts define PUA
codepoints for pictograph glyphs that are not official.

A span element with a title attribute does not always solve this
problem, sometimes the glyph is in a button element that has a title
attribute describing what the button will do rather than the what
the current state is.

For example, a button may show a single loop indicating the media is
currently in single loop mode but have a title attribute specifying
that pressing it enables continuous loop mode.

If there was an alt attribute on a span inside the button, screen
readers could treat the span with a pictograph the same way it would
treat an image child of a button attribute and describe the current
pictograph to the end user.

If there is already a solution to this issue, I apologize, I could
not find one.

We (er, WhatWG / W3C) could just add alt to the global attribute
list too, rather than just span. Or come up with a semantic
pictograph element specifically for this (just like we have tt and
code).

Thank you for opinions.

Re: [whatwg] Allow alt attribute with the span element

[Jonathan Garbee]

Is there a problem with using aria-label
<https://www.w3.org/TR/wai-aria/states_and_properties#aria-label> for this
use case? It seems like this should do exactly what you're asking for in
the given scenario.

On Fri, Oct 6, 2017 at 11:15 AM, Michael A. Peters <mpet...@domblogger.net>
wrote:

> With images, the alt attribute can and should be used to give a
> description of an image for users who can not see the image.
>
> With text, some glyphs are pictographs that have a meaning. For example,
> U+1F502 is a pictograph indicating single loop, but it is meaningless if
> you can not see it.
>
> Even if screen readers can specify the codepoint and/or map the codepoint
> to a description (do they?) sometimes fonts define PUA codepoints for
> pictograph glyphs that are not official.
>
> A span element with a title attribute does not always solve this problem,
> sometimes the glyph is in a button element that has a title attribute
> describing what the button will do rather than the what the current state
> is.
>
> For example, a button may show a single loop indicating the media is
> currently in single loop mode but have a title attribute specifying that
> pressing it enables continuous loop mode.
>
> If there was an alt attribute on a span inside the button, screen readers
> could treat the span with a pictograph the same way it would treat an image
> child of a button attribute and describe the current pictograph to the end
> user.
>
> If there is already a solution to this issue, I apologize, I could not
> find one.
>
> We (er, WhatWG / W3C) could just add alt to the global attribute list too,
> rather than just span. Or come up with a semantic pictograph element
> specifically for this (just like we have tt and code).
>
> Thank you for opinions.
>

[whatwg] Allow alt attribute with the span element

[Michael A. Peters]

With images, the alt attribute can and should be used to give a 
description of an image for users who can not see the image.


With text, some glyphs are pictographs that have a meaning. For example, 
U+1F502 is a pictograph indicating single loop, but it is meaningless if 
you can not see it.


Even if screen readers can specify the codepoint and/or map the 
codepoint to a description (do they?) sometimes fonts define PUA 
codepoints for pictograph glyphs that are not official.


A span element with a title attribute does not always solve this 
problem, sometimes the glyph is in a button element that has a title 
attribute describing what the button will do rather than the what the 
current state is.


For example, a button may show a single loop indicating the media is 
currently in single loop mode but have a title attribute specifying that 
pressing it enables continuous loop mode.


If there was an alt attribute on a span inside the button, screen 
readers could treat the span with a pictograph the same way it would 
treat an image child of a button attribute and describe the current 
pictograph to the end user.


If there is already a solution to this issue, I apologize, I could not 
find one.


We (er, WhatWG / W3C) could just add alt to the global attribute list 
too, rather than just span. Or come up with a semantic pictograph 
element specifically for this (just like we have tt and code).


Thank you for opinions.

Re: [whatwg] The semantics of visual offsetting vs. verbal offsetting

[Qebui Nehebkau]

On 15 September 2017 at 11:49, brenton strine  wrote:
> My understanding of the semantics of  and  vs.  and  is
> that the former indicate a stress, emphasis, offset or importance that
> would be expressed verbally, if reading aloud.
>
> On the other hand, the  and  tags indicate stress, emphasis, offset
> or importance that is visual or typographic.
>
> I frequently see people arguing that  is the most semantic element
> to use for a term or keyword because it is the most "important," but in a
> situation where you would never change the way you read the sentence
> verbally, but rather, just want the typographic indication that it's a
> term. To me, I think this is coming from some ambiguity in the word
> "important" that causes people to fundamentally misunderstand when to use
>  vs .
>
> Is my understanding (i.e., thinking in terms of visual vs. verbal offset as
> a way of clarifying the meaning of the definitions) right here, and if so,
> is there some sort of less ambiguous, authoritative document that I can
> point people to when these discussions come up? Semantics conversations
> always seem to come back to a fundamental disagreement about the meaning of
> the words used in the W3C specification.

The issue has possibly passed its expiration date by now, but no, I do
not think that e.g. the definition of the strong element (as set out
at 
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-strong-element
) is consistent with your understanding. I don't know exactly what the
W3C has to say on the matter at the moment, but most would caution
against relying on their somewhat idiosyncratic perspective.

[whatwg] When to use the new GeolocationSensor API?

[Richard Maher]

When would one opt to use the Sensor GeoLocation
 API as opposed to the
existing standard navigator.geolocation.watchPosition?

Can someone explain the added value of this second API or the use-cases
that can be solved by the sensor API that cannot be handled here
?

The Web App world desperately needs a background geolocation capability but
the sensor API architecturally prohibits this.

What is the point of the following redundant interface to geolocation: -

let sensor = new GeolocationSensor({ accuracy: "high" });

sensor.onreading = function(event) {
var coords = [sensor.latitude, sensor.longitude];
updateMap(null, coords, sensor.accuracy);};

sensor.onerror = function(error) {
updateMap(error);};
sensor.start();

If technical merit contributes to W3C/IETF resource allocation surely the
battery efficient background geolocation solution proposed here
 is what
should be promoted?

[whatwg] The semantics of visual offsetting vs. verbal offsetting

[brenton strine]

My understanding of the semantics of  and  vs.  and  is
that the former indicate a stress, emphasis, offset or importance that
would be expressed verbally, if reading aloud.

On the other hand, the  and  tags indicate stress, emphasis, offset
or importance that is visual or typographic.

I frequently see people arguing that  is the most semantic element
to use for a term or keyword because it is the most "important," but in a
situation where you would never change the way you read the sentence
verbally, but rather, just want the typographic indication that it's a
term. To me, I think this is coming from some ambiguity in the word
"important" that causes people to fundamentally misunderstand when to use
 vs .

Is my understanding (i.e., thinking in terms of visual vs. verbal offset as
a way of clarifying the meaning of the definitions) right here, and if so,
is there some sort of less ambiguous, authoritative document that I can
point people to when these discussions come up? Semantics conversations
always seem to come back to a fundamental disagreement about the meaning of
the words used in the W3C specification.

Re: [whatwg] Expected ratio of ServiceWorker instances to Geolocation Updates

[Richard Maher]

Please be advised that, as promised/threatened, I have added the Trip
Summary page and you can now map and replay your trip on Google Maps.

The new version of the code is at the same link
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

Most important design/proposed-specification change is that TravelManager
subscription should now be Client specific. The TravelEvent must contain
the intended Client.id (TravelEvent.source.id). This means that the UA must
monitor and filter GeoLocation updates per client. I have also added new
demo functionality such as a Trip Summary that is displayed when you press
the "Arrive" button. The trip can also be replayed onto Google Maps by
pressing "Map Trip" or "Replay". If the last and next geolocation updates
for the trip are both visible in the Map window then smooth Marker movement
is achieved via CSS transitions.

*PLEASE* help Background GeoLocation get up and help Web Apps compete with
Native Apps!

If there is something wrong with my TravelManager solution design then let
me know. Tear holes in it!

On Thu, Jul 20, 2017 at 6:36 PM, Richard Maher 
wrote:

> For some time I've been arguing with W3C/IETF (and anyone else who'd
> engage) that ServiceWorkers are the ideal platform to host the Background
> Geolocation functionality that Ultimate Web Apps need in order to compete
> on a level playing field with Native Apps. The sticking point is usually
> the fleeting nature of a ServiceWorkers' lifespan. I have always argued
> that it would be madness to kill them immediately and most implementations
> seem to agree. (Firefox being the most aggressive at 30secs see Bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
> prevails even with heaps of CPU/Memory)
>
> Anyway, in order to prove that I am right, and the likes of Jake Archibald
> are very much mistaken, I wrote a little Web App, Source code can be found
> here: https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
> (There is a aaa_readme.txt) All code is documented full and contains
> meaningful/witty variable names.
>
> Now it still needs a bit of work to provide a trip summary page and map
> the trip on Google maps but I think you'll get the idea and most
> importantly see the real world, actual, demonstrable relationship between
> Service Worker Instances and Geolocation updates? (I wanted to get it out
> before the Europeans disappeared for August
>
> So have I done something stupid here? Am I imagining that I only get a new
> Service worker instance when I'm stuck at the lights for an extended period
> on the way home and position updates are nowhere to be seen? Are my coding
> skills lamentable and testing skills non-existent?
>
> If not, then I have no idea why Web Apps are not allowed to satisfy these
> legitimate and very desirable user requirements. Sure, we'll get
> user-empowerment, permissions, and discovery right but let's get on with
> it? The TravelManagerPolyfill.js file is nearly all UA developers have to
> do!
>
> Q: Have I understood the ServiceWorker architecture correctly and
> implemented a valid heuristic interrogation of ServiceWorker instantiation
> over time?
>

Re: [whatwg] HTML inputs directly toggling CSS classes on elements?

[Jonathan Zuckerman]

class names are meant to be a tiny wormhole which connects the worlds of
content (HTML), presentation (CSS), and behavior (JS)  - I think this
suggestion begins to widen that rip, and it's inadvisable. It's a question
of taste I guess, just which behaviors are primitive enough to not require
javascript.

As you've proven, this idea is easily implemented in Javascript. If you
were to get an incredible rate of adoption for that script, it might
indicate that there is widespread demand for this feature, and you'd be
able to make a case that it's worth implementing in the browser.

On Sun, Sep 10, 2017 at 7:25 AM Roger Hågensen 
wrote:

> On 2017-09-09 18:41, Alex Vincent wrote:
> > A few days ago, I dipped my toes into web design again for the first time
> > in a while.  One of the results is the CSSClassToggleHandler constructor
> > from [1].  Basically, it takes an radio button or checkbox, and turns
> that
> > input into a toggle for a CSS class on another element.
>
> You do have :checked
>
> While I haven't used that with radio or checkboxes much myself it seems
> to at least partially do what you are describing.
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/:checked
>
>
>
>
> --
> Unless specified otherwise, anything I write publicly is considered
> Public Domain (CC0). My opinions are my own unless specified otherwise.
> Roger Hågensen,
> Freelancer, Norway.
>

Re: [whatwg] HTML inputs directly toggling CSS classes on elements?

[Roger Hågensen]

On 2017-09-09 18:41, Alex Vincent wrote:

A few days ago, I dipped my toes into web design again for the first time
in a while.  One of the results is the CSSClassToggleHandler constructor
from [1].  Basically, it takes an radio button or checkbox, and turns that
input into a toggle for a CSS class on another element.


You do have :checked

While I haven't used that with radio or checkboxes much myself it seems 
to at least partially do what you are describing.


https://developer.mozilla.org/en-US/docs/Web/CSS/:checked




--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

[whatwg] HTML inputs directly toggling CSS classes on elements?

[Alex Vincent]

A few days ago, I dipped my toes into web design again for the first time
in a while.  One of the results is the CSSClassToggleHandler constructor
from [1].  Basically, it takes an radio button or checkbox, and turns that
input into a toggle for a CSS class on another element.

This is relatively easy to do in JavaScript, as the very short function
illustrates. I wonder out of simple curiousity if anyone's considered
defining a short set of attributes to do this in HTML itself, without
requiring JavaScript.

Three attributes on the input would be all that's necessary:

   - cssClassName="(word)" would be the class name to apply
   - cssClassFor="(id)" would be an IDREF to the element which would apply
   the class
   - cssClassNot="true" would invert the class enable/disable (so that if
   the input is checked, the class would be removed instead of applied)

I'm of two minds about this.

On the one hand, if HTML can provide a reference from an input to an
element the input is intended to influence, that has to be useful for
reasons similar to the HTML label element's for attribute, and it makes for
one less dependency on JavaScript.  (Accessibility?)

On the other hand, the modern Web has so much dependency on JavaScript.
Also, the HTML input element has a horrendously long list of attributes on
it already.

So, I thought I'd throw the idea out there and see if anyone likes it.

Alex

[1]
https://github.com/ajvincent/es7-membrane/blob/master/docs/distortions-gui/stylesheet.js#L13-L26

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

[whatwg] [ScrollRestoration] API to notify browser when page finished loading?

[Johannes Spangenberg]

Hello,

I was not sure where to ask this question. However, this draft was referenced 
by Chrome and Mozilla. So, hopefully this is the right place. I can also create 
a GitHub Issue at https://github.com/majido/scroll-restoration-proposal/issues 
if you like.

Lets come to the question. If I understand the current draft correctly, it only 
allows disabling scroll restoration performed by the borwser. This means that 
applications still have to implement scroll restoration manually. Other 
persisted user state (like user input on input fields) seems not to be 
considered at all. Do I have understood it correctly?

If I have understood it correctly, I would like to know whether you have 
considered an alternative API as described in the following sentences. 
Basically, the problem seems to be that the browser does not know when the page 
finishes loading. Therefore, my suggestion would be to add an API to notify the 
browser when the page was loaded successfully. An example for such API would be 
a function like this:

delayStateRestoration(promise:Promise) : void

Calling this function would only be allowed while handling popstate event or 
before initial loading of page has finished. Calling this function when the 
page has already been loaded does not make sense.

Yours faithfully,
Johannes Spangenberg

Re: [whatwg] rel=bookmark

[Ed Summers]

> On Aug 8, 2017, at 3:43 PM, Ed Summers <e...@pobox.com> wrote:
> 
> I guess I'll put a contribution together that adjusts rel="bookmark" and see 
> how it fares. Thanks for the feedback everyone.

I started with an issue ticket [1] that references this conversation in case 
anyone is interested in following along there.

//Ed

[1] https://github.com/whatwg/html/issues/2899

Re: [whatwg] rel=bookmark

[Ed Summers]

> On Aug 8, 2017, at 2:04 PM, Kevin Marks  wrote:
> 
> See also http://microformats.org/wiki/sharelink-formats for a (recent)
> related use case
> 
> On 8 Aug 2017 7:01 pm, "Kevin Marks"  wrote:
> 
>> This sounds like what we use uid for in microformats - the url that you
>> want as the persistent identifier.
>> 
>> http://microformats.org/wiki/uid - it looks like you wrote this up a
>> while back, Ed.

Oh boy, that is going back a ways yes :) I see some of that documentation still 
refers to HTML 4! 

I guess I'll put a contribution together that adjusts rel="bookmark" and see 
how it fares. Thanks for the feedback everyone.

//Ed

Re: [whatwg] rel=bookmark

[Kevin Marks]

See also http://microformats.org/wiki/sharelink-formats for a (recent)
related use case

On 8 Aug 2017 7:01 pm, "Kevin Marks"  wrote:

> This sounds like what we use uid for in microformats - the url that you
> want as the persistent identifier.
>
> http://microformats.org/wiki/uid - it looks like you wrote this up a
> while back, Ed.
>
> See u-uid in h-entry http://microformats.org/wiki/h-entry
>
>
>
> On 8 Aug 2017 5:58 pm, "Ed Summers"  wrote:
>
>> Hi Kevin,
>>
>> > On Aug 5, 2017, at 9:19 PM, Kevin Marks  wrote:
>> >
>> > That use case sounds more like rel="canonical"
>>
>> You weren't the only one (myself included) who thought that. Michael
>> Nelson, one of the authors if the identifier I-D, just wrote a blog post
>> explaining why not canonical:
>>
>> http://ws-dl.blogspot.com/2017/08/2017-08-07-relcanonical-
>> does-not-mean.html
>>
>> I think I'm convinced that canonical isn't the right fit for what they
>> are talking about. But if rel=bookmark could be used in  elements I
>> think it would work better than a slightly similar, oddly named, link
>> relation, which IMHO is bound to cause confusion for web publishers.
>>
>> //Ed
>
>

Re: [whatwg] rel=bookmark

[Kevin Marks]

This sounds like what we use uid for in microformats - the url that you
want as the persistent identifier.

http://microformats.org/wiki/uid - it looks like you wrote this up a while
back, Ed.

See u-uid in h-entry http://microformats.org/wiki/h-entry



On 8 Aug 2017 5:58 pm, "Ed Summers"  wrote:

> Hi Kevin,
>
> > On Aug 5, 2017, at 9:19 PM, Kevin Marks  wrote:
> >
> > That use case sounds more like rel="canonical"
>
> You weren't the only one (myself included) who thought that. Michael
> Nelson, one of the authors if the identifier I-D, just wrote a blog post
> explaining why not canonical:
>
> http://ws-dl.blogspot.com/2017/08/2017-08-07-
> relcanonical-does-not-mean.html
>
> I think I'm convinced that canonical isn't the right fit for what they are
> talking about. But if rel=bookmark could be used in  elements I think
> it would work better than a slightly similar, oddly named, link relation,
> which IMHO is bound to cause confusion for web publishers.
>
> //Ed