- From: PhistucK <phistuck@gmail.com>
- Date: Tue, 30 Jul 2013 23:03:54 +0300
- To: Lea Verou <lea@w3.org>
- Cc: Eliezer Bernart <eliezerbernart@gmail.com>, "public-webplatform@w3.org" <public-webplatform@w3.org>
- Message-ID: <CABc02_L3afiuXR-ZNBnTDcW0jQTqBBKK_Aw+uzVs9=qgX-pRRA@mail.gmail.com>
Good comments.
- I also think css/values/others/frequency/... is unnecessarily nested and
should just be css/values/frequency/...
- Yes, the modules level also seems a bit redundant, it does not really
matter, this is not a specification based hierarchy, it is a topic based
hierarchy, so the distinction seems unnecessary.
- By css/values/[type] do you mean css/values/px (for example)? I do think
the category is needed (length), especially since you use this category in
the syntax of the properties. Alternatively, perhaps a css/values could be
a listing page that shows the category and when (as suggested in some other
thread) linking from the <length> in the syntax, you could use the anchor
of the category from the listing page. But I still think
css/value/length/px is better, because it has more immediate visibility
beside going to css/values and beside skimming the page for the category to
which the type belongs.
- This seems a bit problematic. While I do support removing the notations
path, I think it is problematic for those functions to reside only under
css/functions. For example, calc is a special function. It should be in
both of the paths (css/functions and css/values/length), since it actually
serves as a length value and can be used everywhere. However, if you do
that and you also have an image type, should linear-gradient and friends be
there as well?
(By "both of the paths" I obviously mean that one of them would only be a
redirection page)
I do not have a clear solution at the moment... just sharing my thoughts.
My comments -
- Hz and kHz should probably be hz and khz, respectively (all lower case),
unless there are case sensitivity issues of which I am not aware?
- css/values/color/color_by... should probably be css/values/color/hsl (and
similar). A more elaborated representation ("color by hue") should be in a
css/concepts level and not in the reference page. Also, these are also
functions, so... yeah.
Thank you!
☆*PhistucK*
On Tue, Jul 30, 2013 at 9:17 PM, Lea Verou <lea@w3.org> wrote:
> Hi Eliezer,
>
> Thanks for spending so much time researching this issue and writing this!
>
> In general I agree, but I have a few comments:
>
> - The proposed URL structure is needlessly deep. For example, for
> frequency you'd end up with:
> docs.webplatform.org/wiki/css/values/other/frequency. This is not
> guessable and I’d rather have guessable URLs where people who know the
> general structure would just type them in.
> - What does css/values/modules even mean? The fact that some data types
> are more complex and defined elsewhere does not matter for whoever is
> reading the docs, they should still be under values/. That’s why we have
> the Related specifications field.
> - In general, I think we should keep the URL structure shallow.
> css/values/[type] is already deep. We don't need more levels.
> - notations shouldn't be under values/, we have a separate css/functions
> page type, which is easier to guess too. I also think separate functions
> should have separate pages.
>
> Cheers,
> Lea
>
> Lea Verou
> W3C developer relations
> http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou
>
>
>
>
>
>
> On Jul 27, 2013, at 01:25, Eliezer Bernart <eliezerbernart@gmail.com>
> wrote:
>
> > Hello everyone,
> >
> > Some time ago Lea made an observation about duplicate pages, mostly of
> > them about CSS data types, in that occasion Doug and I updated the
> > css/units and css/data_types pages making a little bit more clear and
> > organized. [0]
> >
> > This week on IRC channel, Julee and I talked again about this subject,
> > and how we all are seeing on the mailing list a lot of questions about
> > data types and units organization. Starting from W3C documentation
> > that already exists, we elaborated a structure to discuss the best
> > model inside Webplatform docs for that information.
> >
> > Right now the pages that point to these contents are (some of them
> > created by me and Doug in the last update):
> >
> > + Data Types = http://docs.webplatform.org/wiki/css/data_types
> > - Text values = /css/data_types/text
> > - Color units = /css/data_types/color
> > - Length units = /css/data_types/length
> > - Angle units = /css/data_types/angle
> > - Numeric units = /css/data_types/numeric
> > - Resolution units = /css/data_types/resolution
> > - Time units = /css/data_types/time
> > - Frequency units = /css/data_types/frequency
> >
> > + Units = http://docs.webplatform.org/wiki/css/units
> >
> >
> > Based on CSS Values and Units[1] and Syntax and basic data types[2],
> > the structure proposed is:
> >
> > /css/values
> > |_ /textual
> > |_ /keywords
> > |_ css-wide keywords
> > |_ author-defined identifiers
> > |_ /string
> > |_ /url
> > |_ /numeric
> > |_ /integer
> > |_ /number
> > |_ /percentage
> > |_ %
> > |_ /length
> > |_ absolute
> > |_ cm, mm, in, pt, pc, px
> > |_ relative
> > |_ em, ex, ch, rem
> > |_ vw, vh, vmin, vmax
> > |_ /others
> > |_ /angle
> > |_ deg, grad, rad, turn
> > |_ /frequency
> > |_ Hz, kHz
> > |_ /resolution
> > |_ dpi, dpcm, dppx
> > |_ /time
> > |_ s, ms
> > |_ /modules
> > |_ color [3]
> > |_ colors_by_hue
> > |_ colors_by_name
> > |_ colors_by_saturation
> > |_ user-defined_system_colors
> > |_ image [4]
> > |_ position [5]
> > |_ /notations
> > |_ attr
> > |_ calc
> > |_ counter
> > |_ toggle
> >
> > (New pages are represented by '/' before the name)
> >
> > In the modules node there are the data types that are defined in other
> > specifications, so, should we can just put those at the top level
> > after |_/css (i. e.: color, position) or do you think there's
> > information that would live on a modules page, and then these data
> > types live under modules?
> >
> > It's important remember that the values under notation's node
> > represent complex data types, in module's node the ones which have
> > information defined in other pages, and the others nodes are composed
> > by the primitive values.
> >
> > About the units page [6], I think that is important keep in a page all
> > the possible values, with a link to the data type that each one
> > represents. These unit pages would live under their related data type.
> > I believe that the actual structure is perfect, what do you think?
> >
> > Then there are data types on SVG. There is some differences to data
> > types on CSS, so probably these others informations should be at
> > /svg/[data_type], following some structure in the same way as CSS,
> > just so we do not mix up the things.
> >
> > About the pages' content, themselves, there are some things missing:
> > how-to examples, some better descriptions, some units. But let's work
> > on the structure first.
> >
> > Thanks for the attention. All feedback and opinions will be welcome.
> > This is a really important point that needed to be defined.
> >
> > [0] =
> http://lists.w3.org/Archives/Public/public-webplatform/2013Jun/0055.html
> > [1] = http://www.w3.org/TR/css3-values/
> > [2] = http://www.w3.org/TR/CSS2/syndata.html#values
> > [3] = http://docs.webplatform.org/wiki/css/color
> > [4] = http://www.w3.org/TR/css3-images/
> > [5] = http://www.w3.org/TR/css3-background/#the-background-position
> > [6] = http://docs.webplatform.org/wiki/css/units
> >
> > Eliezer
> >
> > @eliezerbernart
> > eliezerb
> >
> >
>
>
>
Received on Tuesday, 30 July 2013 20:05:01 UTC