Re: Improvements to Web IDL exception message strings

[Domenic Denicola]

On Friday, February 7, 2020 at 8:55:45 AM UTC-5, Boris Zbarsky wrote:
> Hello all,
> 
> We just made some changes to how exception strings from ErrorResult get 
> formatted [1].  The changes apply to both the Throw* DOMException 
> methods and ThrowTypeError/ThrowRangeError.
> 
> In the new setup, exception messages have "%s: " prepended to them, 
> where %s is replaced with one of:
> 
> * "InterfaceName.methodName", when the exception is from a method cal.
> * "InterfaceName.attrName getter", when the exception is from a getter
> * "InterfaceName.attrName setter", when the exception is from a setter
> * "InterfaceName constructor", when the exception is from a constructor.

Would you consider using something that avoids the confusion with static 
methods/properties? E.g.

- InterfaceName's methodName()
- InterfaceName's attrName getter
- InterfaceName's attrName setter

As-is it seems like it would be confusing to talk about, for example, 
Node.appendChild, which is === undefined.

I'm also curious what the output would be for actually-static methods, e.g. 
CSS.escape(), DOMPointReadOnly.fromPoint(), etc.

> 
> The idea is to give web developers a bit more context about what callee 
> failed.
> 
> I have tried to go through existing message strings and remove 
> duplication of that information where it existed.
> 
> The changes only affect exceptions thrown via the ErrorResult that 
> bindings pass to implementation methods.  In particular, Promise 
> rejections via Promise methods (as opposed to throwing on the passed-in 
> ErrorResult) do not benefit from these changes; more work will need to 
> happen there.
> 
> The changes also do not affect exceptions thrown via 
> ErrorResult::Throw(nsresult).  As a reminder, this is deprecated and 
> people should switch to the methods that provide useful error messages.
> 
> Please let me know if there are concerns around this change, suggestions 
> for further improvements, etc!
> 
> -Boris
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613013

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

(On-list this time)

> However, the actual semantics for how list items work are exclusively defined 
> by CSS ([css-lists], [css-pseudo]).
> The above mentioned HTML elements/attributes simply maps to the relevant CSS 
> properties, using a built-in 'list-item' counter.


Where does [css-lists] and [css-pseudo] define this?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

It's great to hear that this isn't a regression in the way I expected. I think 
I was thrown off by the phrasing of the OP, which implied to me a switch from 
following the HTML spec to following the CSS lists spec. As I noted, the CSS 
lists spec contradicts the HTML spec, e.g. disallowing reversed="" from 
affecting the counter values. But it sounds like you're ignoring that part of 
the CSS spec, and instead incrementing (setting?) the list-item counter 
according to the HTML spec's rules.

I remain a bit concerned that the behavior you're implementing here is not 
reflected in any spec at all. This would not matter if this were just internal 
implementation refactoring. However, it's observable to the web via 
getComputedStyle().

Note that the complete list of allowed-per-spec default style changes for li 
elements is given by 
https://html.spec.whatwg.org/multipage/rendering.html#lists , and per 
https://github.com/web-platform-tests/wpt/issues/5625 the CSSWG declared the 
intent to test these requirements via web platform tests.

Introducing new observable behavior with no spec backing, or even opening an 
issue on the relevant specs, seems bad. Reading between the lines, it seems to 
be Mozilla's position that HTML should change to add some CSS rule to the user 
agent stylesheet which modifies counter-set, but not counter-increment. If so 
it'd be much appreciated if folks would open an issue on whatwg/html for public 
standards discussion and work toward cross-browser consensus.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote:


> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element

correction, 
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-li-element
 is where most of the tests landed. The pull request was 
https://github.com/web-platform-tests/wpt/pull/4169 .
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Domenic Denicola]

Some time ago we spent some effort documenting a cross-browser 
mostly-interoperable behavior for list-item-like behaviors, in 
https://github.com/whatwg/html/pull/2002 and linked threads. The result is the 
spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner 
and the tests at 
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
 .

The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to 
contradict that hard-fought consensus. It states simply that

> Additionally, list items automatically increment the special list-item 
> counter. Unless the counter-increment property manually specifies a different 
> increment for the list-item counter, it must be incremented by 1 on every 
> list item, at the same time that counters are normally incremented.

This omits all the details at 
https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
e.g. reversed="", the collection of owned list items, value="" attribute 
parsing, etc.

It seems like a regression to implement list item numbering according to that 
spec, instead of according to HTML.

> web-platform-tests: 

An important thing to test here is the result of getComputedStyle on list items 
as a result of this change. HTML specifies that ordinal values are displayed on 
list items without any counter CSS properties involved, and from what I can 
tell, https://drafts.csswg.org/css-lists/ does not change that. (The appendix 
at https://drafts.csswg.org/css-lists/#ua-stylesheet is informative, not 
normative.) So, including tests that getComputedStyle continues to return no 
results for the counter-related properties or pseudo-elements seems important 
to maintaining interop on this front.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to explore: A declarative low level graphics API that has a simple mapping to CSS

[Domenic Denicola]

Hi Victor,

I'd love to read about this, but am not a Mozillan. Is there a reason the 
document is being kept private?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to ship: SourceMap header

[Domenic Denicola]

From: mozilla.dev.platf...@googlegroups.com 
[mailto:mozilla.dev.platf...@googlegroups.com] On Behalf Of L. David Baron
>
> On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
>> How would I go about starting this?
>> I have never done anything with web standards before.
>
> Probably something like:
>
>  (1) ask the current maintainers of the spec if they're ok with you  doing 
> this

This speaks to the larger issue here, which is finding someone who is willing 
to devote ongoing effort to maintaining the spec. It's a serious long-term 
commitment, not just something to check off the box before shipping a new 
feature. My understanding is there are current maintainers who are happy with 
their workflow using a Google doc. If you want to move to a new technology, you 
need to get them to come along and help with the conversion process, and you 
need to stick around as part of the team committed to maintaining the spec 
long-term, driving consensus on new features.

https://whatwg.org/working-mode may give you somewhat of an idea of how the 
ongoing process of maintaining a spec works. It is for a different standards 
organization than the one dbaron suggests, but the general framework remains.

(BTW, if the spec ends up successful in the WICG, we can talk about migrating 
it from incubation in the WICG to a full-fleged WHATWG specification, as was 
suggested by some people up-thread. But it would be good to see ongoing 
positive signs of engagement first with the proposed new spec.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Domenic Denicola]

(Re-sending as I was informed that "posting by email is not allowed"; apologies 
to those who get this email twice.)

From: mozilla.dev.platf...@googlegroups.com 
[mailto:mozilla.dev.platf...@googlegroups.com] On Behalf Of L. David Baron
>
> On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
>> How would I go about starting this?
>> I have never done anything with web standards before.
>
> Probably something like:
>
>  (1) ask the current maintainers of the spec if they're ok with you  doing 
> this

This speaks to the larger issue here, which is finding someone who is willing 
to devote ongoing effort to maintaining the spec. It's a serious long-term 
commitment, not just something to check off the box before shipping a new 
feature. My understanding is there are current maintainers who are happy with 
their workflow using a Google doc. If you want to move to a new technology, you 
need to get them to come along and help with the conversion process, and you 
need to stick around as part of the team committed to maintaining the spec 
long-term, driving consensus on new features.

https://whatwg.org/working-mode may give you somewhat of an idea of how the 
ongoing process of maintaining a spec works. It is for a different standards 
organization than the one dbaron suggests, but the general framework remains.

(BTW, if the spec ends up successful in the WICG, we can talk about migrating 
it from incubation in the WICG to a full-fleged WHATWG specification, as was 
suggested by some people up-thread. But it would be good to see ongoing 
positive signs of engagement first with the proposed new spec.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Avoiding jank in async functions/promises?

[Domenic Denicola]

On Thursday, May 18, 2017 at 4:34:37 AM UTC-4, smaug wrote:
> FWIW, I just yesterday suggested in #whatwg that the platform should have 
> something like IdlePromise or AsyncPromise.
> And there is the related spec bug 
> https://github.com/whatwg/html/issues/512#issuecomment-171498578

In my opinion there's no need for a whole new promise subclass, just make 
requestIdleCallback() return a promise when there's no argument passed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SharedArrayBuffer and Atomics

[Domenic Denicola]

Great writeup Lars! It's been a pleasure working with you on this.

I just wanted to note that we've finalized the set of Web GL APIs which accept 
shared memory, and that's been deployed into the latest spec, via the pull 
request https://github.com/KhronosGroup/WebGL/pull/2387. You can see the result 
by searching for [AllowShared] in

- https://www.khronos.org/registry/webgl/specs/latest/1.0/
- https://www.khronos.org/registry/webgl/specs/latest/2.0/

This is a decent expansion from the list in your [14]; perhaps there should be 
a tracking bug filed (but certainly not blocking). I hope that one of us (Blink 
or Gecko) will end up submitting appropriate tests to either the Web GL 
conformance test suite or the web platform tests project, to ensure interop.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Domenic Denicola]

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:
> On 10/31/16 9:16 AM, Henri Sivonen wrote:
> > On Oct 31, 2016 16:02, "Mike Taylor"  > > wrote:
> >>
> >>
> >>
> >> On 10/29/16 9:21 AM, Kohei Yoshino wrote:
> >>>
> >>> I think now is a good time to think about navigator.buildID again
> >>> Thoughts?
> >>
> >>
> >> Seems like we'd potentially end up breaking legacy sites that sniff
> > that to mean "isMozilla".
> >>
> >
> > I suggest returning a constant value to general Web sites to avoid this
> > problem.
> 
> I think that's a good path forward.
> 
> -- 
> Mike Taylor
> Web Compat, Mozilla

If Gecko has no plans to remove this and conform to the spec, could someone 
file an issue or pull request on https://github.com/whatwg/html requesting that 
buildID be added to Gecko compatibility mode? 
https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Domenic Denicola]

On Tuesday, May 3, 2016 at 4:24:26 PM UTC-4, Boris Zbarsky wrote:

> In practice, this is the set of  values I'm claiming we 
> support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", 
> "stylesheet", "next", "alternate", "preconnect", "icon".  Anything else 
> I'm missing?  Do we do anything useful with rel="feed" anymore?

Does Firefox support "next" in some interesting way? Maybe it is confusing to 
have it in the spec, but IIRC the idea was that this would be used for people 
trying to figure out if annotating their links with "next" would actually 
affect the user agent's processing or UI in some way.

I, uh, have no idea why we included "next" but not "prev".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: rel="noopener" on links

[Domenic Denicola]

On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:

> 1) This is not feature-detectible, as far as I can see.  So it's not 
> clear to me that sites will know they can use this, short of relying on 
> browser sniffing.

If you implement DOMTokenList.prototype.supports, it should be; supports was 
added specifically for this use case.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: navigator.hardwareConcurrency

[Domenic Denicola]

On Tuesday, March 15, 2016 at 2:08:50 AM UTC-4, Boris Zbarsky wrote:
> On 3/15/16 12:59 AM, Domenic Denicola wrote:
> > Filed https://github.com/whatwg/html/issues/879; should be able to have it 
> > in the spec by sometime tomorrow.
> 
> Thank you.  That's a lot more useful than me snarking, for sure.

Now at https://html.spec.whatwg.org/#navigator.hardwareconcurrency (plus 
https://html.spec.whatwg.org/#navigator and 
https://html.spec.whatwg.org/#workernavigator).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: navigator.hardwareConcurrency

[Domenic Denicola]

On Tuesday, March 15, 2016 at 12:26:21 AM UTC-4, Boris Zbarsky wrote:
> * Link to standard: You're funny.  People don't bother to put stuff into 
> actual specs anymore.  The closest we have is 
> https://wiki.whatwg.org/wiki/NavigatorCores which does at least have 
> some IDL and some discussion around privacy and whatnot.

Filed https://github.com/whatwg/html/issues/879; should be able to have it in 
the spec by sometime tomorrow.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use the Date type in Web IDL APIs

[Domenic Denicola]

On Friday, October 16, 2015 at 3:12:05 PM UTC-4, Jonas Sicking wrote:
> On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky  wrote:
> > So if you want to have value type like behavior, use a value type; for now
> > long long (in IDL terms; Number in JS terms) is good
> 
> FWIW, when the problems with using Date objects in attributes were
> raised with TC39, their recommendation after some debating was to do
> the above.
> 
> / Jonas

I've added this and other related guidance to 
https://w3ctag.github.io/design-principles/#times-and-dates, which might help 
as a reference for if/when this comes up again. (Suggested fixes or 
elaborations welcome.)

I also opened https://github.com/heycam/webidl/issues/66 to see if we can make 
this more clear on the spec level.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform