Giter Site home page Giter Site logo

meetuparchive / sassquatch Goto Github PK

View Code? Open in Web Editor NEW
25.0 125.0 6.0 6.18 MB

CSS foundation & framework for Meetup

Home Page: http://meetup.github.io/sassquatch/

License: MIT License

Ruby 0.16% HTML 14.08% CSS 84.69% Shell 0.19% JavaScript 0.88%
deprecated web-platform

sassquatch's Issues

iOS Safari 6.0.1: `.touchList-item--input input` box hernia 

.touchList-item--input input {
  ...
  width: 100%;
}

Causes box herniation on iOS Safari when changing orientations.

Current hypothesis is that there is an issue with the browser improperly re-calculating and repainting element widths when changing orientation.

For example, after removing the width: 100% property and changing orientation, there was no visible reflow in width.

Now, with the width property active, changing orientation causes a reflow to the landscape width. Changing back from landscape to portrait, the <input> element maintains its calculated landscape width rather than reflowing, breaking the layout in portrait mode.

Make .ffbox--touchList-item and .touchList-gem play nice

Right now .ffbox--touchList-item and .touchList-gem used in conjunction doubles the left padding on the touchList item. However, I'd like to use them and get rid of the span.padding-left inside .ffbox-flex

<li:item action="${scheduleUri}">
  <div class="ffbox ffbox--touchList-item">
    <div class="ffbox-fix">
      <div class="touchList-gem"<i class="icon icon-plus"></i></div>
    </div>
    <div class="ffbox-flex">
      <span class="linked"><trn:message key="group.event.schedule">Schedule</trn:message></span>
    </div>
  </div>
</li:item>

Move _fix-flex and _pin into core

Has been stable in MM for a while; should be moved into core for both desktop and mobile.

Both go together, the pinning being what lets you set certain things to go to the top or bottom of a containing fix or flex cell.

Display icons from Red Label

It would be handy to have a place to see the icons we have available via Red Label on the compiled page for sassquatch

desktop touchList design & bug fixes

We'll need to fix some browser issues and address some design concerns in the desktop touchList css...

  • IE bugs
  • firefox overflow hidden on touch items
  • firefox select height in touchForms
  • hover styles, indicating the entire item is a clickable target

doc update required - tabs and pagination

looks like some class names and/or markup patterns have changed after merging latest from chapstick master.
We should fix the docs, as well as updating the selected state colors.

`.doc-*` Layout and Mobile

Tagging @unjust, @akdetrick.

Problem

One of the things we have kicked around and never really resolved was the issue of layout in single-column environments with "full bleed" (100% width) boxes.

Here's what seems to be the core defaults of existing components:

.doc-box

  • Borders on all sides.
  • Border color
  • Border radius
  • Bottom margin
  • White Background

.doc-content

  • Nesting selector rules when combined with doc-box
  • Transparent bottom border (?)
  • Padding $baseline, except on bottom

.doc-padding

  • Transparent bottom border (?)
  • Padding $baseline, except on bottom.

What doesn't quite work out well for single-column, fix-flex (vertical-centered) layout environments we'll probably see more and more of.

Here are the defaults that seem to cause problems:

.doc-box

  • Borders on all four sides
  • Border radius

.doc-content/.doc-padding

  • Transparent bottom border (seems like it could be removed?)
  • Non-$baseline bottom padding

Questions

  1. Does it seem reasonable to create mobile-layout specific modifiers in the long run, in which we are overriding the Sassquatch-standard definitions?

Example:

.doc-box--full {
  @extend .doc-box;
  border-left: none;
  border-right: none;
  border-radius: 0;
}
  1. Does it make sense to override/redefine problematic selectors?

Example:

// Within mobile sassquatch scope:
.doc-content {
  padding: $baseline;
  border-bottom: none;
}
  1. Does it make sense to create a differently-behaved .doc-* standard, or re-examine the existing defaults?

One potential (half-baked) proposal, would be to have a .doc-card class that behaved like a doc-box, but with consistently-enforceable rules for transitioning between full-bleed and card-like layouts based on media queries and/or modifier classes.

It would be extremely similar to doc-box, but it wouldn't inherit any potential cascade baggage of .doc-box/.doc-padding that would need to be redefined/overruled in mobile stylesheets.

TouchList : Non-parameterized heights

e.g.

.ffbox--touchList-item should use $H_touchTargetDefault instead of 3em.

sassquatch/sass/sassquatch/lib/m/_touchLists.scss : 107
sassquatch/sass/sassquatch/lib/m/_touchLists.scss : 371

touchlist : <li:select> element causes Android Browser Crash

Moved from : https://bugz.meetup.com/show_bug.cgi?id=39349

If li:select is used with the is_disabled parameter set to true, then
clicking on the dropdown arrow will cause the Android Browser to do a complete
crash. So far, only Android Browser is affected.

I haven't been able to figure out why, but I've eliminated:

  • Unicode in the select--mask element.
  • :before or :after in the select--mask element.

Ultimately, I think the issue is how click events and selects are handled in
Android Browser. Because the element is positioned over the to hide browser chrome in certain browsers (Windows Phone, Opera), the
click from the is getting transferred to the beneath it. I don't know why it results in a crash in this case. The fix will likely have to be: Not masking the browser chrome on elements.

  • Making the select--mask some element other than a .
  • Figuring out a JS shim to transfer clicks, and preventing that behavior in a
    disabled state.

    • "audit" modifiers

    we have a few undocumented modifiers... we should document or deprecate depending on usage in chapstick

    we should define standards (browser support, etc) for new additions to sassquatch

    aka the "navbuttons in ie8 problem"

    previously i assumed that sassquatch items were thoroughly tested across desktop and mobile browsers but this may be only half true. perhaps its fine to have mobile only items but then they should be marked as such.

    this also touches on the larger topic of how sassquatch should be maintained. I'm unclear when something is considered for inclusion or if its simply a stand alone item.

    Recommend Projects

    • React photo React

      A declarative, efficient, and flexible JavaScript library for building user interfaces.

    • Vue.js photo Vue.js

      🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

    • Typescript photo Typescript

      TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

    • TensorFlow photo TensorFlow

      An Open Source Machine Learning Framework for Everyone

    • Django photo Django

      The Web framework for perfectionists with deadlines.

    • D3 photo D3

      Bring data to life with SVG, Canvas and HTML. 📊📈🎉

    Recommend Topics

    • javascript

      JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

    • web

      Some thing interesting about web. New door for the world.

    • server

      A server is a program made to process requests and deliver data to clients.

    • Machine learning

      Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

    • Game

      Some thing interesting about game, make everyone happy.

    Recommend Org

    • Facebook photo Facebook

      We are working to build community through open source technology. NB: members must have two-factor auth.

    • Microsoft photo Microsoft

      Open source projects and samples from Microsoft.

    • Google photo Google

      Google ❤️ Open Source for everyone.

    • D3 photo D3

      Data-Driven Documents codes.