Re: [w3c/manifest] Use WebIDL to describe the manifest data structure (#611)

> So is the issue just the naming discrepancy between the manifest fields and normal web attributes ("short_name" vs "shortName")? Or is it more fundamentally that we shouldn't create an IDL that isn't actually exposed on the web?

It's mostly the naming. 

There are advantages (and nice security properties) to having the manifest described in IDL, even if only passed internally. We've had a bug open about this for a couple of years in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1176442  

> 1. Is it inappropriate to have underscores in dictionary fields that are exposed on the web?

IMO, yes. This violates rules in tools like ESLint and makes for inconsistent coding styles. It's not very idiomatic to have underscores in name in JS (or on the web). 

Having said that... it's not like anything would actually break.   

> If so, if we expose manifest members to JavaScript APIs, will we need to expose them under camelCase names instead?

We don't _have to_ ... but we may choose to. 

> If so, should we specify the manifest version and the JS version as two different IDL dictionaries, or have some kind of automated renaming mechanism like Marcos mentioned CSS does.

I don't know how the magic mapping works for CSS, but I'm sure @annevk does (as he worked on CSSOM for a few years)... but there is also `data-foo-bar` attribute in HTML that undergo similar conversion: where that becomes `dataset.fooBar`. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/611#issuecomment-332397574