W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2013

Re: Second JS bulk upload

From: Max Polk <maxpolk@gmail.com>
Date: Sun, 24 Nov 2013 15:48:23 -0500
Message-ID: <CADPfvJs8+UQmK6VJ14jQ_R3UPy_qPtaafjDsCRDS2aQo-QX19g@mail.gmail.com>
To: Webplatform List <public-webplatform@w3.org>
In a dictionary or encyclopedia, everything is at the same top-level
namespace.  In a wiki, in some rare cases subpages can be useful, but to
categorize in Mediawiki, the main approach is to "tag" the page with a
Category:Something inside double square brackets.  You can add multiple
categories.

To diverge from the built-in power of Mediawiki categorization by trying to
replace it with subpages is a mistake.  Just click "random page" over and
over again on Wikipedia and see how many subpages you run into (almost
never).

We already have several top-level subdivisions of webplatform docs, one of
them being the /javascript/ page path.  Let's not use additional paths when
all we need to do is "tag" pages (with a category).  There is even a
facility to list all pages in a category automatically, and you can even
edit that page.  For example, see this:

    http://en.wikipedia.org/wiki/Category:Algebra

It is a category page, with autogenerated page inclusion.  Just "tag" a
page with "[[Category:Algebra]]" and it appears in the category page.  But
you can also introduce the category by editing the category page itself
(the material on the top).

Trying to use subpaths under /javascript/ in this wiki feels to me like a
lack of harmony, awkward, and a divergence from the best strengths
Mediawiki has to offer, especially since the power of "tagging" pages
(categorization) has been completely missing, from all our conversations.

Best approach is to try to tag (categorize) pages first, then, and only
then if that fails, fall back to additional subpage paths.  P.S. it won't
fail.  ;-)



On Sun, Nov 24, 2013 at 2:23 AM, PhistucK <phistuck@gmail.com> wrote:

> It seems a bit messy, to have the API and the language reference (syntax,
> statements, operators) in the same level...
> For example -
> javascript/String
> javascript/Statements
>
>  Also, if we keep them (and I think we should), any non API path
> component ("Statements", "Operators") should be lower case.
>
>
> ☆*PhistucK*
>
>
> On Sun, Nov 24, 2013 at 6:01 AM, Max Polk <maxpolk@gmail.com> wrote:
>
>> The next round of JavaScript pages have just been uploaded.  Root path:
>>
>>     http://docs.webplatform.org/test/javascript
>>
>> The links now work, it should be navigable at this point.  Note that this
>> page, in the original, was intended to the landing page, which pointed to
>> the below top-level pages:
>>
>> http://docs.webplatform.org/test/javascript/JavaScript_Reference
>>
>> Then these top-level pages, in the original, were helpers to point you to
>> the other pages:
>>
>>     http://docs.webplatform.org/test/javascript/Functions
>>     http://docs.webplatform.org/test/javascript/Statements
>>     http://docs.webplatform.org/test/javascript/Operators
>>     http://docs.webplatform.org/test/javascript/Objects
>>     http://docs.webplatform.org/test/javascript/Properties
>>
>> Why are those there?
>>
>> Because we took original html files that were arranged very tree-like in
>> their URL path structure, and began *flattening* to be more like what an
>> encyclopedic venue such as a wiki is good at storing and finding.  By
>> flattening I mean taking out the "Objects/" path prefix to many pages, and
>> things like that.  While we still use subpages, we don't technically need
>> that landing page or the subtopic pages just so everything can be found.  A
>> wiki you simply search for things.  Having said that these pages still look
>> useful to me, although they will probably be reworked.
>>
>> We are messaging the pages to be more like a wiki where URLs are very
>> important, and less like a tech site whose URLs don't always have to make
>> sense.  We want the URLs to be clean.  Fortunately for us, they were
>> already very clean and well organized to begin with.  That definitely is
>> making our flattening effort a lot easier.  Three cheers to organization
>> the pages donator Microsoft imposed, and the good content!
>>
>> The work below is still outstanding:
>>
>>  Automation to do:
>>> 2. talk about static method page name (X/X.method versus X/method)
>>> 3. talk about Global/* (nobody says "Global.decodeURIComponent" so maybe
>>> hide the Global prefix)
>>>
>>> Non-automation to do:
>>> 1. Discuss keeping Object/constructor and erase six other pages
>>> (Array/constructor, Boolean/constructor, etc), that are essentially
>>> duplicates.
>>> 2. Discuss keeping Object/prototype and erase six other pages
>>> (Array/prototype, Boolean/prototype, etc), likewise.
>>> 3. Probably should not erase six other pages for valueOf: (Array/valueOf
>>> , Boolean/valueOf , etc), likewise, since they are each custom versions
>>> that return different things (a string, an array, a boolean value, etc).
>>> 4. Create String/X pages for each of the String HTML Tag Methods
>>> (string.anchor, string.big, string.blink, etc)
>>> 5. Discuss folding arguments/0 n Properties and RegExp/1 9
>>> Propertiesinto their main page then delete them
>>>
>>
>>
>>
>
Received on Sunday, 24 November 2013 20:48:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:55 UTC