On 3/12/18 5:40 PM, Brian Grinstead wrote:
> * It would slow down progress, since we'd need to be rebasing around the entire frontend + tests while migrating a binding.
We could add a hack to NS_NewXULElement that maps some tag names to
others (and creates a new nodeinfo accordingly). This would be used
only on a temporary basis, while migrating a binding. So the workflow
would go like this:
On Mon, Mar 12, 2018 at 10:40 PM, Brian Grinstead
> * It diverges from the spec, so it's another special thing to know about when working on browser chrome compared to content.
We could invest in figuring out
https://github.com/w3c/webcomponents/issues/634. I think we could even
make it so that if your element is not in the HTML, SVG, or MathML
namespace, you don't need a hyphen for its local name. Now if
something like that works well together with our XUL built-ins I'm not
sure. And it's also somewhat unclear whether such an investment is of
interest to other browsers given that the web largely does not care
for non-HTML/SVG/MathML, so it might not end up being standardized
> On Mar 14, 2018, at 7:44 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 3/13/18 4:26 PM, Brian Grinstead wrote:
>> If we could make relaxing the naming rules based on namespace fast
> Can we define "fast"?
> Checking the namespace is fast.
> The work that happens for every element creation for elements that might be custom elements may not be so fast.
>> (either using a whitelist of names or by allowing all non-dashed names).
> The latter is faster to check but slows down creations more. The former is equivalent to my proposal perf-wise.
I don’t know how much extra work we have to do for elements that may be custom elements, but we can do some talos pushes to compare the two approaches. If we added elements to the whitelist right as we convert them and then remove them after the tags are renamed, I doubt that whitelist should ever get too long. The downside is then we can’t do the initial frontend migration in artifact builds, but that’s not a deal-breaker. Or another option that may split the difference would be to have a blacklist of the most common XUL elements that aren’t currently or aren’t going to be custom elements (i.e. hbox, vbox, label, image) and consider everything else valid.
>> 1) Do the binding to custom element migration and land it.
>> 2) Go through and convert all the tag names to the dashed version, landing the conversions as you go.
> This part I'm not following. Which tag name is the custom element definition attached to? It can't be attached to both, iirc….
Yeah, thinking about it more in this version steps (2) and (3) would have to happen all at once in one patch, i.e. no “landing the conversions as you go”. That means we can’t split up the tag renaming into multiple bugs, but as long as it isn’t coupled with the actual binding->CE migration bug I think that’s OK. And I guess (3) would be optional, but having that assertion at least for a temporary period still seems useful in case some system addon or another usage that wasn’t covered by the test suite comes up in practice.