Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

U - Decide what to do with pages for prefixed CSS items #3491

Open
2 tasks
wbamberg opened this issue Jul 16, 2020 · 11 comments
Open
2 tasks

U - Decide what to do with pages for prefixed CSS items #3491

wbamberg opened this issue Jul 16, 2020 · 11 comments
Labels
Content:CSS This is related to CSS content User Story Incremental value deliverable witin a Sprint / Iteration cycle and meeting part of an Epic's AC

Comments

@wbamberg
Copy link

Our CSS docs include about 177 pages documenting prefixed CSS properties, selectors, and so on.

  • These are usually in worse shape than standard items, so will take more work to fix.
  • It will often be difficult to find the information we need (for example, formal syntax can't be taken from the spec if there is no spec, and BCD may be hard to work out for old features)
  • It's likely that we will want to archive some of them if they describe old features that no modern browsers support any more.

We should do an analysis of the pages we have that document prefixed features and:

  • decide which ones we should archive, and archive them
  • work out which updates are needed for the rest, and who will be able help us to supply them.

Acceptance criteria

  • we have decide which prefixed pages to archive, and have archived them
  • we know which updates are needed to the rest
@wbamberg
Copy link
Author

wbamberg commented Jul 16, 2020

I spent today doing some analysis of pages that document prefixed CSS properties. The full details are in this sheet: https://docs.google.com/spreadsheets/d/1xjzL96ihaXfeKyGHyyRAvikg0Zl7558cJ_wJcHwv5AE/edit#gid=1373766696.

The sheet groups pages by vendor and page type: so there is a section for -moz properties, one for -webkit properties, one for -moz selectors, and so on.

For each page I wrote:

  • the last browser version that supported the feature, or "current" if it seems to be still supported
  • whether the page includes the information that the recipe expects. Pages missing this information will be more work to fix. Note that "Formal syntax" and "Formal definition" don't mean that they actually have these H2 sections, just that the page contains the information via a call to {{csssyntax}} or {{cssinfo}}. I've written "n/a" when the recipe does not expect the things (for example, selectors don't have formal syntax or definition).
  • any interesting notes
  • in a few cases, a recommendation on whether to archive the page or not. We should eventually fill in more of these I guess.

Overview

-moz properties

  • 21 pages
  • could archive a few at least
  • most have formal syntax and formal definition
  • several are missing BCD

-ms properties

  • 44 pages
  • all have formal syntax and definition
  • all are missing BCD
  • many are missing examples
  • all have unclear support status

-webkit properties

  • 19 pages
  • most pages have quite complete content

-moz selectors

  • 40 pages
  • many are marked "Mainly intended to be used by theme developers."
  • many are marked "Internal only since Firefox 58"
  • many are missing examples and/or BCD

-ms selectors

  • 14 pages
  • many are IE-only
  • many are missing examples and/or BCD

-webkit selectors

  • 16 pages
  • most are in good shape
  • one needs to be split into 7 pages!

-moz media features

  • 16 pages
  • almost all are marked "Internal only since Firefox 58"
  • almost all are missing examples and BCD

-ms media features

  • 1 page
  • missing examples and BCD

-webkit media features

  • 6 pages
  • mostly in good shape

Questions

  • which of the -moz properties should we archive?
  • what should we do with all the -ms properties and selectors? Which browsers support them? What level of support do we provide for IE these days?
  • what should we do with -moz selectors that are intended for theme developers?
  • what should we do with -moz selectors and media features that are marked internal only?

@Elchi3
Copy link
Member

Elchi3 commented Jul 16, 2020

which of the -moz properties should we archive?

  • All that have been unsupported for at least two years
  • All that are XUL or internal only

what should we do with all the -ms properties and selectors? Which browsers support them? What level of support do we provide for IE these days?

Archive all of them. Given the state the pages are in, they look quasi archived to me already. By archiving, we make it even more clear to web devs that these should never be used again. (Microsoft agreed to archiving and we did that for JS docs already, should continue with CSS now)

what should we do with -moz selectors that are intended for theme developers?

The pages look super small to me and don't provide a lot of info. I propose to write a single document that presents relevant current CSS selectors for theme developers and archive all these old reference pages that are of questionable usefulness in their current form anyway.

what should we do with -moz selectors and media features that are marked internal only?

Archive everything.

@chrisdavidmills
Copy link
Contributor

+1; I think this is a pretty reasonable plan. Trying to get these pages passing the linter is far from a good use of our time.

@Elchi3 Elchi3 added the Content:CSS This is related to CSS content label Jul 16, 2020
@wbamberg
Copy link
Author

@caitmuenster , I'm looking into cleaning up some old CSS pages, and a number of them are marked as "Mainly intended to be used by theme developers." - see rows 91-105 of this sheet: https://docs.google.com/spreadsheets/d/1xjzL96ihaXfeKyGHyyRAvikg0Zl7558cJ_wJcHwv5AE/edit#gid=1373766696.

But I wonder if this is even true any more, since as I understand it only WebExtensions-based themes are supported. So are these pages now obsolete from the point of view of theme developers?

@gijsk
Copy link

gijsk commented Jul 16, 2020

(can the spreadsheet be made public?)

https://jsbin.com/tocalayisi/edit?html,css,output suggests that :-moz-focusring at least is web-accessible (try focusing the button via tab). So I'd be cautious about how many of these can "just" be removed.

@wbamberg
Copy link
Author

(can the spreadsheet be made public?)

Done! Although I don't know how to make it editable to one group and just viewable to another. So now it's view-only for everyone.

https://jsbin.com/tocalayisi/edit?html,css,output suggests that :-moz-focusring at least is web-accessible (try focusing the button via tab). So I'd be cautious about how many of these can "just" be removed.

I didn't read anything in #3491 (comment) that says -moz-focusring is up for archival. The only -moz features up for archival are:

  • those not supported in Firefox for at least 2 years
  • those marked internal-only
  • those marked "mainly intended for theme developers"

@gijsk
Copy link

gijsk commented Jul 16, 2020

https://jsbin.com/tocalayisi/edit?html,css,output suggests that :-moz-focusring at least is web-accessible (try focusing the button via tab). So I'd be cautious about how many of these can "just" be removed.

I didn't read anything in #3491 (comment) that says -moz-focusring is up for archival

It's in the row range you asked about in #3491 (comment) as being intended for theme devs, which is what I looked at after @caitmuenster asked around about that side of things. If we're keeping it, great.

@wbamberg
Copy link
Author

Sorry for any confusion. For theme-specific features I'm interested in ones marked "Mainly intended for theme developers". All of these (except one, row 118) are in the range 90-105. But not everything in that range is also marked "Mainly intended for theme developers".

Having said that. Some items that are marked "Mainly intended for theme developers" are also available to web content. For example :-moz-broken. So perhaps these ought to be kept too?

(Note: we're not actually talking about removing anything, we're talking about "archiving", which means moving them outside the /Web part of the site.)

@wbamberg
Copy link
Author

Adding a note from @Elchi3 on Slack:

when archiving a page and it has bcd, please remove the data from bcd and add plain text to the section like done here https://wiki.developer.mozilla.org/en-US/docs/Archive/Web/JavaScript/Array.unobserve#Browser_compatibility

@wbamberg
Copy link
Author

I've archived the -ms ones and filed mdn/browser-compat-data#6407 to remove BCD.

@wbamberg
Copy link
Author

I've archived some -moz prefixed features:

properties:

-moz-window-shadow
-moz-text-blink
-moz-stack-sizing
-moz-border-top-colors
-moz-border-right-colors
-moz-border-left-colors
-moz-border-bottom-colors

selectors:

:-moz-full-screen-ancestor
:-moz-system-metric + subpages

media features:

-moz-mac-graphite-theme
-moz-maemo-classic
-moz-os-version
-moz-scrollbar-end-backward
-moz-scrollbar-end-forward
-moz-scrollbar-start-backward
-moz-scrollbar-start-forward
-moz-scrollbar-thumb-proportional
-moz-touch-enabled
-moz-windows-accent-color-in-titlebar
-moz-windows-classic
-moz-windows-compositor
-moz-windows-default-theme
-moz-windows-glass
-moz-windows-theme

I've also filed mdn/browser-compat-data#6418 to remove BCD for those features that had it.

@wbamberg wbamberg changed the title Decide what to do with pages for prefixed CSS items U- Decide what to do with pages for prefixed CSS items Jul 28, 2020
@wbamberg wbamberg changed the title U- Decide what to do with pages for prefixed CSS items U - Decide what to do with pages for prefixed CSS items Jul 28, 2020
@chinikes chinikes added this to the Mike November (S2 Q3 2020) milestone Jul 29, 2020
@chinikes chinikes added the User Story Incremental value deliverable witin a Sprint / Iteration cycle and meeting part of an Epic's AC label Jul 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Content:CSS This is related to CSS content User Story Incremental value deliverable witin a Sprint / Iteration cycle and meeting part of an Epic's AC
Projects
None yet
Development

No branches or pull requests

5 participants