Deprecated entries

[m...@flyingsoft.phatcode.net]

Hi,

I often contribute (and use) the MDN pages. Nowadays though there is
just so much deprecated stuff that it is becoming hard to use. I tried
changing a page or two by putting all the deprecated stuff below the
rest, but it's a hopeless endeavor.

I would like to suggest that the deprecated stuff should be hidden (via
CSS/JS) by default... thoughts?

[Jean-Yves Perrier]

Hi!

Do you have an example of these things (in which area)? It would be
easier to understand what you are proposed.

Some parts of the MDN are actively maintained (and the page should be
updated quickly if notified) , others are mostly left over and
deprecated stuff should be removed/moved to Archive/.

--
Jean-Yves

--
Jean-Yves Perrier
Senior Technical Writer / Mozilla Developer Network

[Julien Sphinx]

Hello,

First of all, thanks a lot for your contributions and for reaching out here :)

Under what section do you find that much deprecated stuff? (so that I can get a look at what's the problem).

I'm not sure masking it or hiding it is a good solution (not even if it were obsolete) since MDN goal is to document what is/has been/will be and that historical compatibility is sometimes an issue (own opinion here)

However, I agree that putting this content "lower" in a page (e.g. attributes of a HTML element) is a good idea.

Best regards,
Julien / Sphinx

----------------------------------------
> Date: Wed, 25 Mar 2015 01:04:47 -0500
> From: m...@flyingsoft.phatcode.net
> To: dev...@lists.mozilla.org
> Subject: Deprecated entries

>
> Hi,
>
> I often contribute (and use) the MDN pages. Nowadays though there is
> just so much deprecated stuff that it is becoming hard to use. I tried
> changing a page or two by putting all the deprecated stuff below the
> rest, but it's a hopeless endeavor.
>
> I would like to suggest that the deprecated stuff should be hidden (via
> CSS/JS) by default... thoughts?

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
> Doc project Trello board: https://trello.com/b/HAhl54zz/status

[m...@flyingsoft.phatcode.net]

Thanks!

In response to your requests, here is the big one that I reorganized:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

The problem that I see with just sorting it (maybe automatically,
though?) is that the examples and other notes come after the attributes.
The mere length of the page detracts from its usefulness as a reference.
But, it is better than not sorting it at all, I guess.

As a web developer for a few years now, I do not support very old
browsers, so having the deprecated or unused stuff visible is not a
benefit to me. I do not think that most web developers today would see
it as a benefit, either. It seems that even most (US) government offices
have now upgraded and no longer really need old browser support. I just
feel that the inconvenience for those looking for deprecated or unused
attributes (or other similar content) would be far outweighed by the
benefit of those looking for a more compact and easier to browse
reference.

-Michael R.

[Stephanie Hobson]

I don't do content but I thought I'd mention this in case it's a potential
solution for this or other problems... the dev team recently moved a shim
for details/summary into the javascript for the entire wiki (previously it
only applied to a subset of pages).

It's in use on the Fellowship page (
https://developer.mozilla.org/en-US/fellowship) if you want to see an
example and we can tweak the styling if we have a broader variety of use
cases.

Stephanie.

[Eric Shepherd]

This could be a very useful thing, although we’d definitely want to tweak styling. I would like to be able to have sections for deprecated or obsolete material that could be closed in this way to start with.




I almost wonder if we could have it so that every heading in an article was a togglable section like this, and we could have an attribute on the <hX> block that indicated whether to default to open or to closed; then we could default to closed on the obsolete content.




This would ideally involve some UX to set that stuff up properly, and/or macros for setting the headings up. But wow, we could do some cool stuff with this.


Eric ShepherdSenior Technical Writer

Mozilla

https://developer.mozilla.org/

Blog: http://www.bitstampede.com/

Twitter: http://twitter.com/sheppy

On Thu, Mar 26, 2015 at 12:36 AM, Stephanie Hobson <sho...@mozilla.com>
wrote:

[Stephanie Hobson]

You can specify that <details> should be open by default by adding the open
attribute to the element :) I checked and the shim supports that behaviour
as well.

S.

On Thu, Mar 26, 2015 at 4:47 AM, Eric Shepherd <eshe...@mozilla.com>
wrote:

[Joe Medley]

Whether something is hidden or visible is only part of the issue. I would be nice to show which particular version of a browser deprecated/removed an item. To draw a parallel, new features in Chrome are indicated in compatibility tables with the {{CompatChrome(version_no)}} macro. It would be nice to have equivalent {{DepreChorme()}} and {{RemoveChrome()}}.

I'm not in love with the implementation. I'm just trying to convey the idea.

[Jean-Yves Perrier]

Hi!

I don't think the deprecation is per browser. It is for the whole web.
The fact that Chrome (or another browser vendor) deprecates something is
merely them making official a decision (often implicit). It is similar
to an "Intent to Implement".

The removal of a feature is already stored in the compat data
information. Just without using a macro. Not sure if we want to add new
macros as we will switch to another way of doing thing at the 6-9 months
horizon. Though if it can help scrapping the data, I'm ok with adding a
temporary macro (cc/ing John).

--
Jean-Yves Perrier
Senior Technical Writer / Mozilla Developer Network

[Joe Medley]

My point was that eventually, things go away and when they do, they're dropped from different browsers at different times. That's useful information. Maybe it's not as useful as implementation version, but useful nonetheless. As I said in my original post, I was't pushing a particular implementation, just the idea behind one.

Have I clarified myself?

[Jean-Yves Perrier]

Yes, exactly, removal is important, but a per-browser deprecation not
(as it is deprecated or not at the Web platform level).

On 31/03/2015 20:15, Joe Medley wrote:
> My point was that eventually, things go away and when they do, they're dropped from different browsers at different times. That's useful information. Maybe it's not as useful as implementation version, but useful nonetheless. As I said in my original post, I was't pushing a particular implementation, just the idea behind one.
>
> Have I clarified myself?
>
> On Tuesday, March 31, 2015 at 12:19:15 AM UTC-7, Jean-Yves Perrier wrote:

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
> Doc project Trello board: https://trello.com/b/HAhl54zz/status
>