State of CSS

[SachaG]

Discussing what a State of CSS survey would look like.

[plouc]

• processors
• unit of choice (px, em, rem…)
• positionning/layout (flexbox, css grids, float…)
• libraries
• CSS in JS
• styleguides
• architecture (BEM, atomic…)
• Documentation (Where do you you usually look for documentation about CSS features)
• Browser support
  • Usual constrains
  • Tools/resources used to check support

[SachaG]

I've started a new google doc that we can collaborate on: https://docs.google.com/document/d/1YLh7ZCOt3cSG4rUUJ9KjhVEKRCWvOTUS2VSxFyyKcSs/edit?usp=sharing

[SachaG]

Here's the current survey outline: https://github.com/StateOfJS/StateOfJS/blob/458a8828fe69b4eca2a5a4f2051cf3a7f316e086/typeform/surveys/2018css/outline.yaml

[SachaG]

Some thoughts after generating the actual survey form:

• I will add a way to make certain sections conditional by asking people e.g. “have you ever used a CSS-in-JS library” first before showing all the options
• The “units” section can probably use the “multiple choice” template (check the ones you use) instead of the “feature” template (experimented/used in production/etc.)
• Speaking of which, I’m not sure if the experimented/used in production distinction is useful since it adds one more options to ~30+ questions
• Anything else to add in the “other tools” section besides text editors?
• Not sure how to best handle the "environments" section. I want to find a way to ask about format (tablet/phone/etc.), OS (iOS/Android), browser (Safari/Chrome), etc. but without ending with tons of questions…
• Still missing the "selectors" section but @frivoal is working on that.

[SachaG]

More progress! Pretty happy with this version:

https://stateofjs.typeform.com/to/Zgy95x

• I guess that by putting the initial tool sections behind a yes/no choice we might mess with the integrity of the data a little bit, since it will preselect a subset of respondents for each section. So maybe we should reconsider having that feature?
• Should we offer so pre-filled options for the "what do you feel is missing from CSS" question? Are there common things we could offer as options?

[SachaG]

Note: if you'd like to help beta-test the survey just fill it out as you normally would and then leave your feedback here. I'm curious to know if:

• It's too long
• Things don't make sense or are not clear
• There's things missing
• You'd phrase/organize some questions (or available answers) differently

[frivoal]

• As per Jen's suggestion, move questions about frameworks/pre-processors/tools/methodologies AFTER the questions about CSS. Reason: in order to not lose the people who do CSS but none of these before they get to the questions about CSS.

• rephrase: "Line breaking control" -> "Line breaking properties (white-space, overflow-wrap, word-break, line-break, hyphens)". Reason: Even though these form a set, "Line breaking control" or "Line breaking properties" aren't their official name (they don't have a name as a group), so we need to list them if we want the question to make sense.

• Rename "Feature Support Queries" to "Feature Support Queries (@supports)" or just "@supports". Reason: plenty of people know about it without knowing what it's called.

• "Which of these CSS units do you know about?" add: mm, cm, in

• "desktop browsers do you test in" gives a list that includes non desktop browsers, and fails to include important (in some markets) mobile browsers. Suggestion:

  • split in two (desktop / mobile)
  • move to mobile: Opera mini, ios safari, ios chrome, Chrome Android, Firefox Android, Samsung Internet
  • add to mobile: UC Browser, Opera
  • add to desktop: Opera

  Alternative suggestion: remove the word "desktop" from the question, but still add UC browser and Opera to the mix.

• "Do you write print stylesheets?" answer A/B/C are exclusive of eachother, but D is not. You may have print-only projects (D) some of the time, and projects for which print doesn't matter (A) some of the time. Not sure about the best way to rephrase that.

• Same comment about "Do you write CSS for email clients?"

• In Question "Which CSS-related blogs/magazines/etc. do you read?", rename "The CSS Spec" to "The CSS Specs" (plural).

• "CSS stands for…": does not seem like a very useful question, nor a very funny joke. I'd remove it.

[SachaG]

Great feedback! And thanks for the selector list!

[SachaG]

Do you write print stylesheets?" answer A/B/C are exclusive of eachother, but D is not. You may have print-only projects (D) some of the time, and projects for which print doesn't matter (A) some of the time. Not sure about the best way to rephrase that.

My thinking was that we can probably assume that anybody who answers (D) would probably care about print styles for their other projects too? I agree it's not quite the same, to be honest I mainly added (D) because of our conversations on that topic.

[frivoal]

I wanted to answer B+D: I never print websites, so I don't care all that strongly about their print stylesheet. However, I have made retail books using css (e.g. The Japanese version of Lea Verou's CSS Secrets), and I generally use HTML+CSS=>PDF as a replacement for MS-Word.

For the email question, I also suspect that the answer will be mostly A or A+D.

It's not perfect, but I think we could just keep the questions as is, and switch to allowing multiple answers. Since answering A+B or A+C or B+C is not meaningful, I suspect that mostly people just won't do it, and it allows people to actually do (A or B or C) + D.

[SachaG]

Updated: https://stateofjs.typeform.com/to/EQfX1U

Re: print/email thing, I'll think about it. Allowing multiple answers seems a bit weird so maybe we just add a separate question for print-only projects.

[frivoal]

Updated: https://stateofjs.typeform.com/to/EQfX1U

I went through it again. I like the new iteration.

Some more comments:

• The table of content is now out of sync with the reordered content.

• For the units / selectors. The question is currently "Which of these *** do you know about?" Since there may well be things in there that people know about but actively chose to stay away from, I think a slightly more interesting question would be

  "Which of these *** do you consider being part of your toolbox (i.e. know about and use at least occasionally?)"

  or maybe

  "Which of these *** do you use at least occasionally?".

  Over the years, that could also let us observe trends of people giving up on old tools as they adopt new ones (for example, I suspect people will mostly stop using :focus once :focus-visible becomes mainstream, even though they probably won't stop knowing it exists).

• in "other tools", I'd add one more question:
  Which browser's dev-tools is your primary one for working on css:

  • Firefox
  • Chrome
  • Safari
  • Edge
  • Other ?

  Reason: that's different (although overlapping with) than the browsers you test in. I also suspect that preferences in dev tools vary depending on whether people primarily do CSS, or primarily do JS, so looking into that could be interesting.

• in print stylesheet / email stylesheet, I suggest a minor rephrasing: "I almost never write CSS for emails" -> "I (almost) never write CSS for emails".

• At no point during the survey do we ask people if they also do JS. I think it would be good to, as I suspect that there are quite a few questions where the answers will strongly correlate with that. Maybe ask it this way:

  In addition to CSS, I also write JavaScript

  • Never
  • Small bits here and there, but that's not really my thing
  • A lot
  • More than CSS, actually

  You could possibly also ask that about HTML and SVG, and maaaaaybe "server side stuff".

[SachaG]

"Which of these *** do you consider being part of your toolbox (i.e. know about and use at least occasionally?)"

I think the issue is that if the question we ask is more vague, the answer will also be more vague (and there's also the issue that "occasionally" is very subjective). With that phrasing we'd have no way of knowing if people chose an option because they know about it; or because they use it. So I'd rather pick one or the other.

I think the scenario of things that people know about but choose to stay away from is rare enough that we can ignore it.

[SachaG]

At no point during the survey do we ask people if they also do JS.

How about we add these options to the question about job titles then:

• Front-end Developer (HTML/CSS only)
• Front-end Developer (HTML/CSS/JS)

[SachaG]

Which browser's dev-tools is your primary one for working on css:

How about:

Which browser(s) do you work in primarily during initial development?

Some people might not use DevTools that much but still have a preferred development browser?

[SachaG]

Updated: https://stateofjs.typeform.com/to/WAF41k

[SachaG]

Line breaking properties (white-space, overflow-wrap, word-break, line-break, hyphens)

This one seems weird to me, as it imo mixes one very common property (white-space) with others I've never used/heard of. I might suggest removing it, although I know you care about this topic… ;)

[SachaG]

And I'm considering changing "which of these do you know about" to "which of these do you have you used" for units and selectors. I think that'll give us more meaningful results, since it's more precise than "know about" (you've either used it or you haven't).

[loklaan]

Hey great survey! I really like the scope of questions in the css features section 👌 I came from the beta-tester request on twitter.

Here is some feedback I'd love to give, and hopefully it is helpful:

• As Florian mentions, there isn't a question about using JavaScript. I think the post-analysis of the survey would benefit from expanding on this suggestion. It'd be great to see how different kind of frontend developers are writing css, given our humble title has exploded with responsibility over the past few years with heavier frontend apps. I'm new to designing surveys, but here is an alternative suggestion to Florian (linear amount of js mightn't give enough context) & yourself Sacha (can't picture people introducing themselves at parties with the different langs they use).
  How much JS code do you write?
  1. No JS, only pure HTML and CSS
  2. Some JS, on websites built with HTML and CSS.
  3. I build HTML and CSS websites and apps with JS.
• Maybe this is too much, but I think CSS in JS section could be a part of the prior CSS Methodologies section. Reason: Most of the libraries automate the prior mentioned methadologies. By lumping them together we might see clearer results about how people are shifting metholodogies.

[frivoal]

This one seems weird to me, as it imo mixes one very common property (white-space) with others I've never used/heard of. I might suggest removing it, although I know you care about this topic… ;)

This is a set of properties that heavily interact with each other, and if you're trying to solve the sort of problem for which you need to reach for one, you often need to consider the whole set. However, given that white-space is much more common that then other properties in this list, I could indeed be reasonable to remove it from the list (assuming that people do use it), and just ask about the rest. Or we could split the question to ask separately about each property, but that's probably overkill.

[frivoal]

I think the scenario of things that people know about but choose to stay away from is rare enough that we can ignore it.

I don't think it's that rare. Example:

• people who think you should side everything in em or rem exit. That doesn't mean they don't know about px. (the same is true the other way around).
• people who think you should never use the physical length unit exit. That doesn't mean they don't know about inches or millimeters.
• As your question about selector nesting suggests, people know think it is best not to use nested selectors / descendant combinators exist.

And I'm considering changing "which of these do you know about" to "which of these do you have you used" for units and selectors. I think that'll give us more meaningful results, since it's more precise than "know about" (you've either used it or you haven't).

I think that would be fine, if we can exclude those that they don't intend to use again.

[frivoal]

How much JS code do you write?

• No JS, only pure HTML and CSS
• Some JS, on websites built with HTML and CSS.
• I build HTML and CSS websites and apps with JS.

For someone who works alone, that's fine, but none of the answers seem right for someone who writes mostly HTML and CSS, and a little bit of JS, whitin a team that mostly makes things in JS.

I don't know if it is meaningful to ask the different between "I don't write JS, but people I work with write a lot of it" and "there's mostly no JS in my life, regardless of who writes it". Maybe there is, maybe not. But both realities exist, so we should phrase the question in a way that doesn't confuse either crowd.

[davidluhr]

This is shaping up really well! Couple pieces of feedback:

1. I would consider adding a couple questions to the Resources section. Perhaps there could be a question regarding online courses, and another regarding YouTube channels or video series. CSS is so visual that a lot of valuable resources are found in these media.
2. I would move the question "What do you feel is currently missing from CSS?" from the "About You" section into the "Opinion Questions" section. I have a feeling a lot of people will want to give responses to this question.

Really excited for this survey!

[SachaG]

Perhaps there could be a question regarding online courses, and another regarding YouTube channels or video series.

@davidluhr are there popular courses/channels that most people know about? I personally have never used either, so I wouldn't really be able to come up with a list…

[SachaG]

And for the JS question, how about introducing two new questions:

Front-end Proficiency

How proficient are you at JavaScript development? (pick the most advanced option corresponding to your skills)

• I am not able to write any JavaScript
• I can write short, simple JavaScript or jQuery statements
• I can work on existing front-end codebases using modern frameworks (React, Vue, etc.)
• I can architecture entire front-end codebases and handle advanced patterns (state management, data loading, etc.)

Back-end Proficiency

How proficient are you at back-end development? (pick the most advanced option corresponding to your skills)

• I am not able to handle any back-end work
• I can set up all-in-one CMSs (WordPress, etc.)
• I can develop apps using pre-existing frameworks (Rails, Laravel, etc.)
• I can set up an entire back-end from scratch (Go, Node, etc.)

[loklaan]

@SachaG That's straight to the point and also covers backend consistently - I think it'd be great addition to the survey!

[SachaG]

Btw this is super rough but for the logo and general theme I was thinking of doing something blueprint-themed:

[frivoal]

I don't like the "front-end proficiency" framing. It has a very strong implication about "the normal way" to be a web developer these days.

It implies that someone who knows HTML and CSS (and SVG and ARIA and EPUB and WCAG and Open Type and RDFa and Illustrator and Photoshop and InDesign and typography and color theory) is not "fully proficient", while someone who knows CSS and a lot of JS is.

That's one particular career path, but there are others. Asking it this way seems very hostile to people who learned their skills in a different way than "cool kids these days".

I'm less of a backend person, but I feel a similar bias to some degree in the question. This seems to match the dominant way of leveling up these days, but it doesn't seem to have room for the people who've never done any of that, but can write enough php to get stuff done, or the people who write the web-facing config panel in your home router in C++, or the people who make your bank's website...

I don't think there's anything wrong with asking whether people can do the various things you're asking, but I do think there's a problem with implying that these particular things (and these things only) are the scale on which we can judge how advanced people's skill are.

[SachaG]

ok, maybe "JavaScript proficiency" is less controversial then? for the back-end question I'm not sure how else to frame it though…

[SachaG]

So basically, although I'm sure there are still some points we could improve here, I'll consider the questions 95% done and move on to designing the landing page for the survey; and once that's done everything will be ready for publication. This should take me about a week, which still leaves time to tweak things a bit.

In the meantime if there's anything that you mentioned in this thread but that I didn't address feel free to remind me again :)

[SachaG]

I'm putting the finishing touches to the landing page, which means we'll be able to launch soon.

Should we mention CSS Exclusions btw? https://webdesign.tutsplus.com/tutorials/an-introduction-to-css-exclusions-the-future-of-complex-web-layout--cms-32366?ref=webdesignernews.com

[SachaG]

Landing page preview! https://stateofcss.com/

Password: CSS

Feedback welcome :) But please don't share yet!

[loklaan]

@SachaG Looks great! I can't wait to see the rest of the survey design 😻

Here are some things I did manage to sleuth:

• The individual authors can become too small in width; I'd suggest having a minimum size of 200px or so.
  Saw you're using css-grid, very nice, accomplish with:
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
• favicon is 404ing
• Lighthouse is firing for some key concerns, like a11y and meta data

[SachaG]

@loklaan great feedback! Still learning grid, thanks for the pointers :)

[frivoal]

Should we mention CSS Exclusions

They're an interesting technology, but they're Microsoft only, with some strong objection (not to the concept, but it's actual design) from other vendors. So they're kind of dead by default, but if we actually have a bunch of people showing interest in them, that could be used to try and revive it, which would be interesting. So I'd be in support of including them, but if you'd rather not, that's ok as well.

[frivoal]

• The social links (twitter / facebook / email) all mention stateofjs instead of stateofcss
• the <title> is still "The State of Javascript 2018"
• The "State of CSS" svg illustration doesn't load in firefox
• If you resize the width down until the logo goes above the text, there's a narrow (16px? same size as a scrollbar?) white bar on the side
  

[SachaG]

Hmm strange… in Firefox I found that the SVG shows up fine, but then disappears when you open the devtools!

[SachaG]

Oh it disappears when the window is below a given height. I'll look into it tomorrow.

[davidluhr]

Looking great! So excited for all of this.

Some markup feedback:

1. The <h1 class="Home__Logo">) doesn't contain any actual text, and the SVG does not have an accessible name.

• Because screen reader support for <title> in an SVG is inconsistent, I would recommend adding hidden text in a <span> that's nested in the <h1> that reads "The State of CSS 2019" with the following CSS properties to visually hide it, but ensure it is still accessible to screen reader users:

  padding: 0;
  width: 1px;
  height: 1px;
  position: absolute;
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(0 0 99.9% 99.9%);
  overflow: hidden;
  border: 0;

• Additionally, the SVG should have aria-hidden="true" so screen readers know this SVG is decorative/redundant with actual text content.

2. "CSS is evolving faster than ever." should be in an <h2> instead of a <p> tag, because it functions as a heading in terms of content hierarchy and there are <h3> tags subsequently in the same content section.

3. The email input (<input type="email" class="Newsletter__Email" id="field_0" …/>) does not have an associated <label>. I would recommend adding <label for="field_0">Email</label> with the same CSS used above to hide the <h1> text. This will ensure the label is still accessible for screen reader users. Placeholder text has inconsistent support across screen readers, so it is best to always provide a dedicated <label> for each input.

4. <h3 class="About__Author__Name"> headings should be <h4>, because their parent heading ("The State of CSS is Made by:") is a <h3>.

[SachaG]

@davidluhr great feedback! I'll change that right away. Btw I'm surprised there isn't a better way to hide something visually but still make it accessible to screen readers? I thought that would've been standardized somehow by now since it's such a common need.

[davidluhr]

@SachaG I agree completely. The code snippet I posted above is well-tested and used widely, but it is unfortunate that we have to resort to hacks to ensure our websites are accessible.

The updated markup looks great!

[SachaG]

I'm running into a very weird bug in Chrome where there's extra padding below the main layout, outside of the bounds of <body> and <html>…

[SachaG]

Apparently it's caused by the individual .Block elements in the right column having a margin-bottom. Super strange…

[SachaG]

Actually it's not related to margins, it's just that the longer the right column's content is, the more it pushes down the bottom of the overall page. The weird part is that manually setting the height to 200px with overflow: hidden for the entire right column doesn't change anything, the content is still "jumping out" and pushing down the entire window's bottom edge.

[SachaG]

[davidluhr]

@SachaG Interesting. This issue is appearing in all Chromium-based browsers on both Mac and Windows. Firefox looks fine on both platforms.

Not sure of the exact cause of the issue, but the following seems to fix it without negatively affecting the site in other browsers:

@media screen and (min-width: 800px) {
  body {
    overflow: hidden;
  }
}

[SachaG]

It does seem like overflow: hidden on the body fixes the issue but there's still some really weird behaviors. For example the browser seems to "remember" scroll position and I get stuck at the bottom of the page.

If I open a new incognito window, the browser properly loads the page at the top:

Still in most cases it shouldn't matter. Thanks for finding the fix @davidluhr !

[bryndyment]

does the bug go away if you swap out CSS grid for flexbox?

[SachaG]

No actually, I tried that as well and it didn't make a difference.

[SachaG]

OK, I think we've worked out all the kinks so I'll launch this whole thing tomorrow (morning Japan time). I'm excited to see what people think!

[davidluhr]

@SachaG Awesome! Can't wait to take part. So excited for the world to see.

[SachaG]

One thing I'm really enjoying is all the people saying that merely taking the survey taught them about a lot of CSS concepts they didn't know about.

So for the results site, I would love to go deeper in that direction and really explain each CSS property mentioned.

Obviously writing all of that from scratch would be a huge amount of work, so I wonder if we couldn't leverage MDN? Is the MDN content available via an API? Or could it be scraped? For example:

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_Snap

[plouc]

Using MDN will require to use the same license => https://developer.mozilla.org/en-US/docs/MDN/About#Copyrights_and_licenses

[plouc]

You can easily get the pages' content by appending $json to the URL, for example https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout$json

[SachaG]

Oh perfect. The license shouldn't be a problem. All we need to do is add the URL for each page to each question then.

[frivoal]

In addition to MDN (which I wholeheartedly support), I'd also include a link to the specifications. Most of them are written to be quite readable for authors as well as implementers.

[SachaG]

The MDN pages have links to the spec but it doesn't seem like they're exposed in the JSON API sadly… :(

[frivoal]

The whole list of features isn't that long. I can easily provide links manually for everything you want to have a link for.

[SachaG]

Thanks to everybody who helped out in this thread! After a long, long time we're now almost done :) You can preview the results and leave us your feedback here:

Devographics/StateOfCSS-2019#29