Re: sample CSS property page: font-size

On Thu, Jan 24, 2013 at 6:56 PM, Paul Irish <paulirish@google.com> wrote:
> Hey guys!
>
> Mike, you've done great work here. :D

Thx!

> Some feedback from Nicolas Gallagher, lead dev of HTML5 Boilerplate and
> Normalize.css:
>
> it's quite impressive!
> 'values' is missing 'initial'

Meaning, you can specify "initial" as a value, similar to "inherit". A
couple of issues here.  A value of "initial" can be applied to all
properties, and "inherit" to a lot of them, so I see it as background
info. We should consider whether it should be reflected redundantly on
each property page. If so, it should be generated from the supplied
info in the metadata table.  (I hard-coded "inherit" in the mockup b/c
I wanted to see how keywords appear distinguished from variables.)

You reminded me to include a bit about default style sheets. At some
point when the dust clears I'll update the actual WPD page to reflect
all this.

> 'compatibility table' is confusing, not clear what it's showing. is the top
> part showing compat for all units that aren't `vh/vw` etc?
>
> "Basic support" ?

I included a th[colspan] for "Basic support." I believe the optimal
way to process the final page is to leave out that span when that's
the only feature considered, which will probably be the vast majority
of cases. If there are sub-features, include spans for all of them. I
tried including the "Basic support" span when there were no
sub-features, but thought it looked horrible. (TBC, this vh/vw
sub-feature is only here for the purpose of design mockup.)

>  the examples need to be more explicit by setting a fixed, known base
> font-size. 16px is an assumed desktop default but afaik some mobile devices
> use large values. so the 62.5% example is a bit old-school.

I'm hazy on this issue, but on mobile think it's probably safer to
rely on the browser's "medium" than a fixed-pixel value. Granted,
they're both variable & optimized per-device.

> "Other resources" says "css tricks" but points to ALA article. it's also
> from 2007, which might have some dated info...didnt check.
>
> My feedback:
>
> Logos are out of date. I would recommend grabbing some Chrome/IE/Opera
> updates from https://github.com/paulirish/browser-logos  - I really like the
> table design though.

Will update soon.

> "Requires a !DOCTYPE declaration" .. some doctypes are specified to trigger
> quirks mode.. so better: "Requires standards-mode" Might be better to link
> to a standardsmode/quirksmode link.

I changed it so that now it's linking to two nonexistent pages rather
than one. ;-)

> I really think WPD would benefit from pointing to more external articles
> that frame each docs page with community discussion of its uses. In this
> case..

I included a couple of those. I think it best to discuss web-design
standards for readable text (e.g., optimum line length/height) as part
of a tutorial.

> https://github.com/h5bp/html5-boilerplate/issues/724 Discussion of what a
> good default font-size is.
> http://clagnut.com/blog/348/ is actually where Richard Rutter introduced
> 62.5%, but the ALA article that's currently linked proposed an improvement
> http://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake/
> makes a strong case for designing with a larger font-size.
>
> Discussing the pros/cons for sizing fonts would be a good addition to the
> page, but it's hard to wade into this area with objectivity.
>
>
>
> On Thu, Jan 24, 2013 at 8:28 AM, Mike Sierra
> <letmespellitoutforyou@gmail.com> wrote:
>>
>> Re #5, I modified my list of suggested template/design enhancements
>> (http://docs.webplatform.org/wiki/WPD:Proposals/css_prop_enhancements)
>> to capture what kind of changes they are & help decide which are more
>> important. SKIN is for minor CSS tweaks; TEMPLATE has to do with how
>> content generates in the final page; FORM has to do with any necessary
>> modifications to how content is input.
>>
>> --Mike Sierra
>>
>>
>> On Wed, Jan 23, 2013 at 10:04 PM, Alex Komoroske <komoroske@google.com>
>> wrote:
>> > I also just added more steps to the CSS Property Milestone plan [1] to
>> > capture the work to prove out this page design on a few other articles,
>> > and
>> > also to implement the necessary template changes.
>> >
>> > [1] http://docs.webplatform.org/wiki/WPD:Tasks/CSS_Property_Milestone
>> >
>> >
>> >
>> > On Wed, Jan 23, 2013 at 7:01 PM, Alex Komoroske <komoroske@google.com>
>> > wrote:
>> >>
>> >> I sat down to provide detailed commentary on this page, and... I don't
>> >> really have much. :-)
>> >>
>> >> It looks great overall to me.
>> >>
>> >> Here are a few random thoughts:
>> >>
>> >> How does the very short right-aligned description relate to the
>> >> one-line
>> >> overview? They seem to substantially overlap in terms of information in
>> >> this
>> >> case, although I could imagine the overview might have more information
>> >> for
>> >> more complicated properties.
>> >> The "See CSS Text Styling Fundamentals for an overview." looks a bit
>> >> out
>> >> of place as a prose parenthetical tacked on the end. Should that be
>> >> presented in a more structured way?
>> >> The green check marks draw a bit too much attention because that all of
>> >> the other cells in the overview table are just text.
>> >> We need to carefully think about the compatibility table design; this
>> >> is a
>> >> complex area and we shouldn't jump into a given design without
>> >> considering
>> >> the consequences. Font-size is a pretty straightforward property, but
>> >> other
>> >> complications to consider include: how to show that support started
>> >> prefixed
>> >> at one version and unprefixed at another, as well as how to include
>> >> information about sub-compatiblity information. For example, MDN's
>> >> box-shadow page [1] has four separate rows for basic support,
>> >> multiples,
>> >> inset, and spread radius. That said, I like this compatibility design a
>> >> fair
>> >> bit; the use of color for supported status makes it work both at a
>> >> glance
>> >> and when you want specific versions.
>> >>
>> >> Thanks for doing such an awesome job on this!
>> >>
>> >> --Alex
>> >>
>> >> [1] https://developer.mozilla.org/en-US/docs/CSS/box-shadow
>> >>
>> >>
>> >> On Wed, Jan 23, 2013 at 1:23 AM, Chris Mills <cmills@opera.com> wrote:
>> >>>
>> >>> Thanks for your continued work on this Mike - your comments all make
>> >>> sense to me. Just one specific thing you asked for comment on:
>> >>>
>> >>> The question of font-size: 62.5% versus font-size: 10px - this is a
>> >>> good
>> >>> point, and I think that these days it makes very little difference; it
>> >>> used
>> >>> to be that in the old days, using pixel sizes was bad because old IE
>> >>> versions couldn't zoom content sized in this way. But that is a
>> >>> problem of
>> >>> the past, pretty much.
>> >>>
>> >>> Chris Mills
>> >>> Opera Software, dev.opera.com
>> >>> W3C Fellow, web education and webplatform.org
>> >>> Author of "Practical CSS3: Develop and Design" (http://goo.gl/AKf9M)
>> >>>
>> >>> On 22 Jan 2013, at 22:20, Mike Sierra
>> >>> <letmespellitoutforyou@gmail.com>
>> >>> wrote:
>> >>>
>> >>> > On Tue, Jan 22, 2013 at 3:34 PM, Mike Sierra
>> >>> > <letmespellitoutforyou@gmail.com> wrote:
>> >>> >> On Tue, Jan 22, 2013 at 2:22 PM, Mike Sierra
>> >>> >> <letmespellitoutforyou@gmail.com> wrote:
>> >>> >>> Great comments. Replies inline marked SIERRA below.  I think it's
>> >>> >>> wise
>> >>> >>> to keep a tally of the major template/skin enhancements necessary
>> >>> >>> to
>> >>> >>> produce this suggested design -- will do that.
>> >>> >>
>> >>> >> As promised, a list of features needed to fine-tune the design:
>> >>> >
>> >>> > At Julee's suggestion, I captured these suggestions as a proposal
>> >>> > here:
>> >>> >
>> >>> > http://docs.webplatform.org/wiki/WPD:Proposals/css_prop_enhancements
>> >>> >
>> >>> > --Mike Sierra
>> >>>
>> >>>
>> >>
>> >
>
>

Received on Friday, 25 January 2013 15:39:02 UTC