My Slides from InControl 2012: What We Don’t Know

I know it’s weird to go through slides of a presentation outside of the context of a real talk (and pales in comparison to the experience of being there) but nonetheless, there may be bits of goodness you can extract from them.

[Slides are embedded, come to site to view them or view on SpeakerDeck]

These are my slides from InControl 2012 where I did a talk I called “What We Don’t Know” sort of based on this post. Here’s the short of it:

On any given request for our website there are many unknown factors. One of the more obvious unknowns is the browser. There are lots of techniques and tools we can use to ensure good experiences across any browser. But we also don’t know about the person. Who are they? Where to they live? What are they thinking? We should be admitting that we don’t know those things either. And how does that person interact with their browser? And how does that browser interact with the server behind our website? These are all unknowns. The first step is admitting it and the next is embracing it.

My Slides from InControl 2012: What We Don’t Know is a post from CSS-Tricks

Source: CSS-Tricks

 

I can’t design in the browser

Sarah Parmenter with some good honest thoughts about the popular idea of designing in the browser.

I’ve tried, goodness knows I’ve tried, but my designs end up suffering, looking boxy, bland and uninspiring.

Not that I’m that great of a designer but I feel the same way. I have to start in Photoshop to get anything decent looking. I try to get out it as soon as possible, but once I’m into the HTML/CSS my brain is in a more analytical and less creative mode.

Direct Link to ArticlePermalink

I can’t design in the browser is a post from CSS-Tricks

Source: CSS-Tricks

 

Everything You Ever Wanted to Know about the CSSWG -webkit- Discussions (AKA Minutes and Resolutions Paris F2F 2012 / Telecon 2012-02-15: Vendor Prefixes and -webkit-, Property Aliasing)

-webkit- Problem

It should be noted that this has been a topic of passionate discussion, and that it will take awhile not only for the CSSWG to agree on and execute a plan of action, but even for the Members to understand the nuances of each others’ positions. For example, Mozilla, Opera, and Microsoft are aligned on there being a problem that desperately needs addressing, potentially with desperate measures; but not on the exact details of what is problematic or how exactly to address which parts.

Part I: Monday

Discussed problem of WebKit monopoly on mobile and the consequent pressure for other engines to implement -webkit- properties. See also Tantek’s questions on designing a course of action.

Full minutes

Part II: Tuesday

Discussed specific actions WG can take to ameliorate the situation. Three approaches are available; chairs assert the WG can use all as needed:

  • Dropping prefixes before CR (via legacy clause in the prefixing policy documented at /TR/CSS)
  • Splitting specs to move stable features faster (as is being done with CSS3 Text)
  • Asking the chairs to assign high priority to those features (as done with CSS2.1 leading up to its REC)

Full minutes

Part III: Wednesday

  • Brief discussion of whether to drop prefixes pre-CR for Transforms, Transitions, and/or Animations.

Full minutes

Part IV: Telecon

Discussed -webkit- prefixing situation and how to move forward on Transforms. Considerations included:

  • whether to exceptionally unprefix transforms immediately or follow through with the process to CR.
  • whether Transforms spec needed to be split into SVG/CSS or 2D/3D or some other way.
  • whether to move to CR while deferring all issues raised by the merge
  • whether to publish LCWD immediately, how long of an LC period would be
    required, and how long it would take to finish resolving the issues

No consensus positions were found, and all parties left the telecon frustrated.

Time estimates for finishing work on Transforms however were agreed to be within 2-3 months if appropriately prioritized.

Full minutes. Anyone interested in this topic should also read the www-style follow-up by Sylvain Galineau (Microsoft).

Aliasing

Aliases are used both for vendor prefixed / unprefixed property pairs as well as for the word-wrap/overflow-wrap property and for the page-break-* properties (which are aliased to break-*). We discussed what, exactly, aliasing means:

  • Resolved: When a browser supports multiple syntaxes of a single property, they’re treated as aliases in the cascade, such that last wins. In the OM, all variants show up, with equivalent values, regardless of which version was specified or which won.
  • Resolved: The last resolution applies to WG-approved aliases. It MAY be used by browsers for handling prefixed versions as well.
  • Resolved: When value aliases are supported, return the version that the author provided.
  • Resolved: In media query feature strings, also return the version that the author provided.

Full minutes

Source: CSS WG Blog

 

Things It Might Be Fun/Useful to Try the Universal (*) Selector On

Paul Irish recently wrote a post on using the universal selector to set border-box box-sizing on everything:

* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

I’ve been wanting to try that for a while and I’m happy to say I’ve used it on a few projects already and it’s awesome. It also got my thinking what other properties might be similarly useful in applying to all elements on the page.

Transitions

* { -webkit-transition: all 0.2s ease; -moz-transition: all 0.2s ease; -ms-transition: all 0.2s ease; -o-transition: all 0.2s ease; }

If you’re on a desktop browser, try it out right now. Open your browsers dev tools and add a new CSS rule. I happen to be in Chrome so:

I just tried in in the WordPress dashboard where I’m writing this and it’s pretty wacky fun, especially in the side navigation. Performance could certainly be a concern here, so I’m not exactly advocating it’s use right now, but it’s fun to play with. When everything on the page has a quick and equal transition, I find it a nice, softened, comforting feel.

Non-Repeating Backgrounds

I bet overall you tell backgrounds to no-repeat more often than you actually leave them repeating.

* { background-repeat: no-repeat; }

That way you can do:

.logo { background-image: url(logo.png); }

Without worrying that the image you’ve set will repeat and be weird if the container is slightly bigger than the logo. And you also don’t have to use the shorthand for background, which sets/resets background-color, background-attachment, and background-position whether you want it to or not.

I know Estelle Weyl is a fan =)

Relative Positioning

* { position: relative; }

If everything starts out with relative positioning, that means z-index “just works” instead of the confusing issue where default statically positioned elements ignore it. It also means it’s easier to nudge things around with top, left, right, and bottom which all “just work” on relatively positioned elements. It might be hard to apply this to an existing layout but starting from scratch with this shouldn’t be too hard.

Middle Alignment

* { vertical-align: middle; }

I find myself setting this value a lot, espeically on projects that use icons. It doesn’t affect much on most layouts I tried applying it on, as it only really comes up when inline or inline-block elements line up with each other on the same line. Essentially, I find myself setting this more than resetting a default, which I think makes it a good candidate for universal settage.

Things It Might Be Fun/Useful to Try the Universal (*) Selector On is a post from CSS-Tricks

Source: CSS-Tricks