848308 - We need MDC to better document the styling of form controls using pseudo elements

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: CSS, defect)

Description

[Jonathan Watt [:jwatt]]

It's currently very hard for content authors to figure out from our documentation how they can use the pieces of anonymous content that form controls contain to style those form controls. We should better document them.

Webkit example: http://trac.webkit.org/wiki/Styling%20Form%20Controls

I'm not sure whether we should have a dedicated page like that one, or if the pseudo elements should be documented on the pages for the various HTML form control elements. Note that for <input> the pseudo elements change as its "type" attribute changes.

Comment 1

[Jeremie Patonnier :Jeremie]

(In reply to Jonathan Watt [:jwatt] from comment #0)
> It's currently very hard for content authors to figure out from our
> documentation how they can use the pieces of anonymous content that form
> controls contain to style those form controls. We should better document
> them.
> 
> Webkit example: http://trac.webkit.org/wiki/Styling%20Form%20Controls

If it's about documenting non-standard pseudo-class and pseudo-elements, this should be documented here : https://developer.mozilla.org/en-US/docs/CSS/CSS_Reference/Mozilla_Extensions#Pseudo-elements_and_pseudo-classes

There is a few hints (and a strong warning that it's very bad practice to use that for Web content) about Mozilla specific CSS features for HTML Form here : https://developer.mozilla.org/en-US/docs/Advanced_styling_for_HTML_forms

Does this fit your expectation or are you looking for something more specific ?

> I'm not sure whether we should have a dedicated page like that one, or if
> the pseudo elements should be documented on the pages for the various HTML
> form control elements.

Sorry to said that, but documenting proprietary features on the standard part of MDN will be done on my dead body!

There is a clear objective to make the web standard part of MDN as much neutral as possible by avoiding Gecko specific feature inside standard content. I'm much more in favor of a dedicated page about that and a link to that page from the standard part. Actually, I would also be in favor of documenting WebKit and MS specific features if they are not yet documented on the WebKit Trac or on MSDN.

The objective is to draw a clear line between what is standard, what is about to become a standard and what is vendor specific.

Comment 2

[Jean-Yves Perrier [:teoli]]

I have a middle position here.

- We need to document our specific pseudo-elements and pseudo-classes, both linked from the page given by Jeremie and by a specific page à la WebKit.
- We also need a page for -ms- and -webkit equivalent pseudo-classes/elements (I prefer when Web devs looking for these w/ Google findour neutral page, with the info that it is non-standard)
- And we need a summary page with info for all three engines: unfortunately, people are using them on the Web and it is better that they use it correctly.

Of course, these pages will come with the usual warnings ("Non-standard" banner and eventually, info about "the right way". The idea is that Web devs use our pages as a reference when building Web sites, and that way if they decide to use these styling elements they will at least been reminded about the other browsers. Styling forms is one of the Web Compat problems that we face right now.

I'm not in favour of mixing it inside <input> (which is insanely long anyway), but a link to the info from there should be ok.

Jonathan : do we have a list of form-related pseudo-classes/elements and the structure of the replaced form elements for Gecko? (Either in a handy way, or the link to the right files/lines in the code).

Comment 3

[Eric Shepherd [:sheppy]]

I agree with everything teoli said here. I also think the <input> doc is a terrible mess, and we need to fix it, so I've just filed bug 861235 for that.

Comment 4

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.