ControlUICustomization - Common HTML structure for views

[jcgregorio]

In the Open Questions you raise the following issue:

Allowing the developer to clear the default styles and provide their own stylesheet isn't a solution, because different platforms may have used a different HTML structure to build their control views. E.g. the slider track might be built with styled <div>s in one platform and styled <span>s in another.

I'm so glad you pointed this out because I incorrectly assumed that the complete HTML structure of each control would be fully specified.

I strongly believe that unless the entire structure of the contro is specified completely this entire specification will end up as an interoperability nightmare and everyone will stick to writing custom controls.

So the same developer-provided stylesheet would not work interoperably unless the entire control UI was replaced.

This is the core of the problem, it puts the onus of interoperability on the developer instead of on the browser.

[dandclark]

I'm inclined to agree with this. I think we'll need to do some experimenting to see how robust the user-slotted parts are to changes in the control HTML structure. If we don't come up with a way to minimize interop issues, we might have to go further than OpenUI is currently going in restricting allowable differences in the default control HTML structure across browsers.

Given how much we're specifying in OpenUI, including the structure of the control anatomy (the parts, and their parent/child/sibling relationships) and the location of <slot>s, it might not actually be a huge leap from there to specifying the exact HTML. This too would require experimentation to ensure that we could arrive on a common HTML structure with enough flexibility that different UA stylesheets could morph it into what each browser wants their default to look like.

[mfreed7]

While I agree with the core of this issue, I'm loathe to jump all the way to specifying the full HTML structure. I'm guessing implementers will balk at that, for good reasons. Is there a reason why we would need to specify, for example, the HTML structure of all of the "accent" pieces of each control? For example, what if a UA wants a floating SVG logo behind one of the controls - do need need to specify a part of the control for that?

Perhaps the best approach is to move ahead with specifying just the parts that are required for each control, and see how far that goes. The example given (the <input type=range>) is one place where more specification might be necessary, to allow interoperable sliders and tracks. However, I'm not sure that it naturally follows that we need to fully specify the entirety of the HTML of all controls. Perhaps we incrementally specify the parts that turn out to be necessary, and leave the rest as un-specified as possible. There should be less argument against the specs in that case, as there will be motivating facts to back each of them up (e.g. the slider/range issue).

[gregwhitworth]

Perhaps the best approach is to move ahead with specifying just the parts that are required for each control, and see how far that goes.

100% agree. I'd like to get buy in on the general model and see willingness from other UAs on implementing against this model before taking that next step.

@jcgregorio I should note that this has been discussed by the editors of the proposal as well as in other meetings with members of the CSSWG. We plan to try and investigate this but it's a layer above this and isn't required to validate the model and get general agreement from UAs.