XUL magic attributes in a HTML world

[Dave Townsend]

So as we move away from XUL elements we're going to have to consider what to do about some of the element attributes that XUL currently uses to apply style effects to the element. Things like orient, pack, align, flex. All of these already have CSS equivalents (both for the XUL box model and HTML flex) but as we switch to HTML elements the attributes will no longer be read by the platform.

There are a couple of things we could switch to and I'd like to hear thoughts from the front-end team:

One is to switch them all to the style properties instead, so <box style="-moz-box-orient: 'vertical'/>.

Another is to require content stylesheets for every element used in this way.

The other is to define some default CSS rules applied based on attribute: [orient="vertical"] { -moz-box-orient: vertical } This works for attributes with a finite set of options but it would be harder to use this for flex or ordinal (unless the platform team end up implementing attr() support.

Bear in mind that this doesn't just apply to markup, we set some of these properties from JS too.

What alternatives sound good?

[Bobby Holley]

Universal attribute selectors are generally slow, so we should avoid them. Let's get input from the layout team about how the style system could handle this most-efficiently and account for that in the eventual decision.

_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Matthew N.]

On Thu, Nov 7, 2019 at 11:11 AM Dave Townsend <dtow...@mozilla.com> wrote:

So as we move away from XUL elements we're going to have to consider what to do about some of the element attributes that XUL currently uses to apply style effects to the element. Things like orient, pack, align, flex. All of these already have CSS equivalents (both for the XUL box model and HTML flex) but as we switch to HTML elements the attributes will no longer be read by the platform.

There are a couple of things we could switch to and I'd like to hear thoughts from the front-end team:

One is to switch them all to the style properties instead, so <box style="-moz-box-orient: 'vertical'/>.

Note that this would interfere with disallowing 'unsafe-inline' in a Content Security Policy so we'd have to be careful with that and consider whether it makes more work to enforce CSP on more documents later. This could be fine as a migration step for existing UI if it helps with issues of specificity but perhaps we could try to avoid this for new UI.

 

Another is to require content stylesheets for every element used in this way.

I believe there is a fair amount of new UI already created which doesn't rely on these attributes (e.g. about:logins) and I haven't felt like it was a burden.

 

The other is to define some default CSS rules applied based on attribute: [orient="vertical"] { -moz-box-orient: vertical } This works for attributes with a finite set of options but it would be harder to use this for flex or ordinal (unless the platform team end up implementing attr() support.

 

I would prefer this over @style for doing a mass transition (since it doesn't have the problem of CSP) if performance concerns can be addressed.

Bear in mind that this doesn't just apply to markup, we set some of these properties from JS too.

What alternatives sound good?

I think the high level question is whether we want to continue using content attributes for this kind of styling in the future or whether we're fine using stylesheets for it. Personally I don't find that the content attributes in question significantly ease UI development (some could argue that they complicate it since some styling is via CSS and others via attributes) so I'd be fine with requiring the use of these properties from custom rules in stylesheets (at least in new UI) for new code.

[Brian Grinstead]

Thanks for raising this topic Mossop,
I've been thinking about this a lot lately and have a rough working plan for how to strip away stuff like this from XULElement to ease mass migration to HTMLElement wherever possible. I'm interested in the feedback from your post so we can modify the plan as needed.

Here's the outline of my current plan as it relates to these magic properties:

1) Stop reading the [align], [pack], [dir], [orient] attributes from directly inside the moz flexbox implementation and instead rely on new CSS rules in xul.css (basically the `[orient="vertical"] { -moz-box-orient: vertical }` stuff you mention). This fixes some xul flexbox bugs since we will be actually setting the style on elements. Here's a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=1592369.
1a) Depending on feedback here especially regarding performance considerations, I was considering making helper classes like `.orient-vertical { -moz-box-orient: vertical }` and rewrite [orient=vertical] in markup/js to use class instead.
2) For the non-enumerable attributes (flex and ordinal), make some helper classes for the most common uses like `.flex-1` and if you don't want one of those values then you set it in a separate CSS file. Here's a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=1593303.
3) Remove the JS properties (.flex, .orient, etc) and use setAttribute instead. Here's a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=1593023.

Brian

[Brian Grinstead]

FYI: barring any additional feedback, we are going to start working through this plan. Related work will be tracked in this metabug: https://bugzilla.mozilla.org/show_bug.cgi?id=1596497.

Brian