tylerchilds / cutestrap Goto Github PK

Dead project?

I thought wrapper-small should be replaced with wrapper wrapper--small

even the inline docs hint at this
<div class="wrapper {{modifier_class}}">Wrapper</div>

I wonder why you are using 960px grid. This is commonly used because it is easy to divide by 2,3,4,5,6 - so great for 12columns grid. But your grid is implicit, so you are not limited to such size and you can use something, what would use far better the available viewport for different types of common devices, and it would be your great advantage.

The css arrow in select boxes (.field select+.label::after) is not clickable (Chrome, Firefox, others). This is an issue to users who aim for that very arrow when trying to use the menu, and give up if that doesn't work (a behavior seen in real usage testing).

I think the solution might be as easy as adding an pointer-events: none; (well, not for Internet Explorer, but Cutestrap forms don't really work with IE anyway)

Can you guys port this to stylus?

Stylus is more in line with npm ecosystem, supports almost the same things as sass and has no external (non-npm) dependencies.

todo: investigate: https://github.com/nickvaud/cutestrap/commit/03205b7efc6f52f1c1ae9b8995c1f3c8d5d5af48

You can use Sharps grid for building grid on BEM.

I like this project, and would love to use this in future proof-of-concepts I build. I noticed though that there doesn't seem to be a built-in way to set the color of elements based on context, like in Bootstrap where you can for example set btn-danger on a delete-button.

It's easy to add yourself in your project, but from a UX point of view I feel like it might be too important to not include as a default. Do you agree? It would also help for those who just want a good-looking proof-of-concept without having to add custom CSS.

I'd suggest using the same classes for all elements to keep it consistent, perhaps ctx-primary, ctx-success, ctx-warning, etc? I can try making a pull request if you think this is a good idea to add.

When installing the node_modules for this project, there were several errors thrown during the npm install:

npm WARN deprecated [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
npm WARN deprecated [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated [email protected]: cross-spawn no longer requires a build toolchain, use it instead!
npm WARN prefer global [email protected] should be installed with -g
npm WARN prefer global [email protected] should be installed with -g

Then, when bower install in run, this is thrown:

(node:8568) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.

Finally, gulp fails as well:

(node:8632) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
module.js:442
    throw err;
    ^

Error: Cannot find module 'gulp-include'
    at Function.Module._resolveFilename (module.js:440:15)
    at Function.Module._load (module.js:388:25)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/edensg/Desktop/Desktop/GCVI/McCrae Day/styleguide/cutestrap/gulpfile.js:10:21)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

I'm not sure how much of this you have control over and how much is just a result of dependencies and their messiness. Would it worth trying other (older) node versions perhaps, or are there other things that should be installed (locally or globally)?

example: https://jsbin.com/lacoco/edit?html,output

source: https://twitter.com/lommes/status/737295224683266049

The text link is not fully accessible since it relies on color alone to denote that it's a link.

Suggestion 1: return the underline. (highly recommended)

Suggestion 2: provide more visual affordance that the standalone text is a link such as adding an icon.

WCAG references:
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-without-color
http://www.w3.org/TR/WCAG20-TECHS/F73.html

PS:
Since this is a link, strange that it's listed under Buttons and the class names say button.

There was a bug in older Chrome where REM units on the body tag weren't applied correctly: https://bugs.chromium.org/p/chromium/issues/detail?id=319623
I'd advise using em or % for the font-size and line-height on the body tag to cater for this just in case

Using spans as demonstration for buttons and links promotes using non-semantic elements that aren't accessible without added code that developers get for free with the semantic versions.

Current button/link demo code is

<span class="btn">Default</span>
<span class="btn btn--secondary">Secondary</span>
<span class="btn btn--link">Link</span>

I recommend making it:

<button class="btn">Default</button>
<button class="btn btn--secondary">Secondary</button>
<a href="#" class="btn btn--link">Link</a>

a should be used when navigating to another point on the page or another page.
button or <input type="button" /> should be used when taking an action on the page (submitting a form, opening a modal, sorting a table, etc.). The button element is preferred as developers can include icons, images, and hidden text to keep them accessible and flexible.

Recent accessibility standards recommend using explicit labels with form elements. in order to achieve this use the for attribute in the label pointing to the id of the field.

Wrapping the label around the input creates an implicit label, and while not wrong, has inconsistent performance among assistive technology, like screen readers.

Current Cutestrap form HTML is

<label class="textfield">
      <input type="text">
      <span class="textfield__label">Your Name</span>
    </label>

I'm recommending modifying the suggested code to be:

<div class="textfield">
    <label for="name">  
      <span class="textfield__label">Your Name</span>
    </label>
    <input type="text" id="name">
</div>

Base body font size should be 100% not 62.5% and break points done with ems not pixels

can we get a class for flexbox columns? eg .cgrid { display: flex; flex-direction: column; }

Hi, thanks for the great project.

I have been looking through the documentation and spotted some variable references like the following example:

html {
    --color-primary-tint: hsl(350, 100%, 80%);
    --color-primary: hsl(350, 80%, 60%);
    --color-primary-shade: hsl(350, 60%, 40%);
}

Source: https://www.cutestrap.com/features/themes

But after inspecting the code for the project, I can see that many of these variable names differ slightly. In the case of the above, they are suffixed with numbers, e.g. --color-primary-tint1, source: https://github.com/tylerchilds/cutestrap/blob/master/src/css/core.css#L39

I have noticed this in a few other locations too. Does the documentation need updating?

Serve minified cutestrap over a CDN, perhaps jsdelivr.

There is a small typo in README.md:

Only nest for psuedo-elements

On one hand I'm just curious what the design choice here was about; on the other hand there's an issue when there's an <img> element within a container with .ta-center/.ta-right -- the image won't respect the text alignment. This can be worked around however by setting appropriate margins on the image:

.ta-center img {
  margin-left: auto;
  margin-right: auto;
}

.ta-right img {
  margin-left: auto;
}

• Mac OS X El Captian
• MacBook Pro (Retina, 15-inch, Mid 2015)

Chrome 53.0.2785.143 (64-bit)

label.textfield (height: 50px)

label.select (height: 48px)

label.textfield > input (height: 50px)

label.select > select (height: 48px)

Firefox 49.0

label.textfield > input (line-height: 24px)

is IE supported?

I really like the minimalism of Cutestrap, but I have found myself fighting with the button styling when trying to use semantic markup in my nav elements. I was recently reading through BEM naming conventions and noticed that it specifies "No tag name or ids" for CSS selectors. Conversely, Cutestrap docs state that "A default button is applied with the .btn class or automatically on button tags or button/submit inputs."

Is this implementation of tag styling in Cutestrap intentional? Am I referencing incorrect documentation for BEM?

The two sets of source files are slightly out of sync. Namely...

• dd padding/text-indent in _base.scss;
• margins and classnames for .wrapper-large and .wrapper-small in _grid.scss; and
• padding on .radio and .checkbox in _forms.scss.

It looks like /dist/scss/ is the canonical version, but then what's the point of the /src/sass/ directory?

I thought it might be cool to start a contrib repo under cutestrap user where the public can add modules without it being part of the base build. This keeps the core light, but has easy modules to pull in. It would mean probably declaring vars at the top of each component file though.

My big two additions

• navbar / nav
• cards
• buttons additional
  • primary, secondary, warn
  • outline
  • lg, sm
  • block

When using the multiple attribute with a element, the arrow to the right should probably be hidden. Additionally: The label text should probably be positioned above the content, so that it is not overlaid when scrolling. (There might be a few other tweaks as well) edit: image embedding seems broken, but here's an example of the current behaviour: https://user-images.githubusercontent.com/122874/73550240-864ed680-4444-11ea-83a9-b0c70de96807.png (Chrome)

If you set the .toolbar (first child of <body>) to position: sticky you won't need to set a margin-top on the <html> which is easier to maintain and allows writing less styles if you want to change the height/elements within the top nav at different media query breakpoints. I wonder if it's more performant for mobile devices as well 🤷🏼‍♂️ I remember apple.com had their top nav (mobile only) using position: sticky but now they are using position: fixed 🤔 (Though that appears to be for the blur effect they have)

I think you havent consider rendering performance in first place as this is introduced as a "one page" framework but i believe doing some tweaks wont hurt anyone.

Using .grid > *, really? How about .grid > div, .grid > section, .grid > article at least ? or better to use an identifier for columns ?

When a .label after an <input> of type=radio and type=checkbox is within a .field that has display: inline-block (i.e. <label class="field -inline">) the browser will not respect the cursor: pointer style applied to the .label (The cutestrap style .field [type=checkbox]+.label, .field [type=radio]+.label { cursor: pointer })

You can demo what I mean on the cutestrap.com homepage under 'Forms'. 'Cone' and 'Bowl' radios do not show a pointer cursor (except when hovering the radio ring/dot because it's a pseudo ::before element). But the 'Add Sprinkles' checkbox before the submit does show a pointer cursor over the label text (because it's not within a display: inline-block <label>.

It seems like setting cursor: pointer directly on .field [type=radio], .field [type=checkbox] is acceptable (I'm not necessarily an expert) and that would solve the issue.

I haven't used the light framework yet but it seems awesome and how I like to write CSS since I don't have to support anything but the latest browsers. Thanks for great work @tylerchilds.

Is there any way to do forms with a mix of 1 and more columns? Right now the grid > &first-child and &last-child margins will mess things up if you don't put all the form inputs in a grid. If you do put them in a grid, then any dropdown arrow will end up off of the form element.

I think it would be nice to set the text selection colors based on the current theme settings:

::-moz-selection { background: yellow; }
::selection { background: yellow; }

The challenge here being that we may want to consider a dark mode implementation too.

Would you consider a PR that brings in the following utility?

.screen-reader-text {
  border: 0;
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  word-wrap: normal !important;
}

Description: Allows items to be hidden visually but spoken via screen reader.

i set the disabled value on a few elements, instead of adding a disabled class; cutestrap should style both cases

if a user types in a text area, the label will overlap the text content.

you should probably update to using stylelint.io for a linter, it's a more modern linter than csslint

with the recent [disabled] styling, button groups are bugged:

<button disabled>one</button><button>two</button>

the first and second button will be styled as disabled

Can not use the !important qualifier in the AMP HTML site.

https://www.ampproject.org/docs/reference/spec.html#important

Usage of the !important qualifier is not allowed. This is a necessary requirement to enable AMP to enforce its element sizing invariants.

https://github.com/cutestrap/cutestrap/blob/d9985d1/src/sass/support/_base.scss#L286

/* remove yellow from chrome auto-fill background */
input:-webkit-autofill,
textarea:-webkit-autofill,
select:-webkit-autofill {
  color: $gray1;
  -webkit-text-fill-color: $gray1;
  -webkit-box-shadow: 0 0 0px 1000px white inset !important;
}