723 Matching Annotations
  1. Apr 2020
  2. Mar 2020
    1. We were not satisfied with the basic capabilities like bold and italics so we built CSS. Now, we wanted to modify some parts of the HTML/CSS in response to things like clicking things, so we implemented a scripting language to quickly specify such relations and have then run within the browser itself instead of a round trip to the server.

      Birth of CSS - advanced styling

      (history of websites)

  3. Jan 2020
  4. Nov 2019
  5. Oct 2019
  6. Sep 2019
  7. Aug 2019
    1. CSS syntax is awesome for two reasons: It is an order of magnitude faster and less resource intensive than the more complex XPath. When what you want to find can be found with a css selector, a corresponding XPath query doing the same would most of the time be much longer and harder to read.
  8. Apr 2019
  9. Feb 2019
    1. or use a CDN hosted version by CDNJS <head> <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/animate.css/3.7.0/animate.min.css"> </head>

      You can add the link to css in your head

  10. Jan 2019
  11. Dec 2018
  12. Oct 2018
  13. Sep 2018
    1. let root = document.documentElement; root.addEventListener("mousemove", e => { root.style.setProperty('--mouse-x', e.clientX + "px"); root.style.setProperty('--mouse-y', e.clientY + "px"); });
  14. Oct 2017
    1. using the style tag and writing the CSS inside it or by using the link tag to link to a style sheet. Either of these tags go in the head portion of your HTML. 

      How to include CSS in a page/site. Goes in the Head

      1. Use <style> tag or</li> <li>Use <link> tag that points to a style sheet.</li> </ol> </style>
    2. One of those themes was reusability. You could describe a style once in CSS and reuse it across multiple elements or even multiple web pages. 0:31Another of those themes was maintainability. Being able to efficiently change your web page in response to changing design requirements. 

      Why CSS

      1. Reusability
      2. Maintainability
  15. Sep 2017
  16. Aug 2017
  17. Jun 2017
    1. Hot Module Replacement (HMR) builds on top of the WDS. It enables an interface that makes it possible to swap modules live. For example, style-loader can update your CSS without forcing a refresh. As CSS is stateless by design, implementing HMR for it's ideal.

      Hot module replacement (HMR) and CSS (or LESS/SASS)

  18. Mar 2017
    1. Now we have a new contender for the best-system-to-build-html-layouts trophy (trophy title is a work in progress). It is the mighty CSS Grid, and by the end of this month, it will be available natively in Firefox 52 and Chrome 57, with other browsers (hopefully) following soon.

      Highlight

  19. Jan 2017
    1. Anyone using that older browser should have access to the same content as someone using the latest and greatest web browser. But that doesn’t mean they should get the same experience. As Brad Frost puts it: There is a difference between support and optimization. Support every browser ...but optimise for none.

      This is why HTML (content) must be separated from CSS (layout) and javascript (interactivity). Content is the core functionality. CSS are displayed through progessive enhancement.

  20. Oct 2016
  21. Sep 2016
  22. Jul 2016
    1.   #map { height: 100%; }

      isn't html and body already declared as having height of 100%?

      Why isnt' that enough?


      ANS :

      "Note that divs usually take their width from their containing element, and empty divs usually have 0 height. For this reason, you must always set a height on the

      <div> explicitly."

      </div>
  23. May 2016
    1. Figure 6-1 shows how the font metrics apply to glyph dimensions, and Table 6-1 lists the method names that correlate with the metrics. See the various method descriptions for more specific information.

      Useful diagram illustrating the various metrics of fonts. Unfortunately many of these are not currently accessible using Web Platform APIs.

  24. Mar 2016
  25. Feb 2016
    1. This is a perfect use-case for @extend. These rulesets are inherently related; their shared traits are shared for a reason, not coincidentally. Further, we aren’t transplanting their selectors hundreds of lines away from their source, so our Specificity Graph stays nice and sane

      So a sensible policy might be to use @extend only for related classes in the same source file, where source order is obvious.

    2. Some useful notes on the pros and cons of @extend vs mixins in SCSS.

      In a nutshell, he suggests avoiding @extend entirely.

      My main bugbear is that it prevents local reasoning about the final set of rules that will apply for an element with a given class.

  26. Jan 2016
    1. In Lesson 1 we discussed using a CSS reset to tone all of these default values down to zero. Doing so allows us to work from the ground up and to specify our own values.

      I'm not sure if I need to do this.

  27. Dec 2015
  28. edwardtufte.github.io edwardtufte.github.io
  29. Oct 2015
    1. Consolidated all our HTML resets into a new module, Reboot. Reboot steps in where Normalize.css stops, giving you more opinionated resets like box-sizing: border-box, margin tweaks, and more all in a single Sass file.

      Worth having a look into the Reboot module to see what the reset involves and the rationale.

      Note that normalize.css is used as a baseline, with styles from reboot.scss applied on top.

      See https://github.com/twbs/bootstrap/blob/v4-dev/scss/_reboot.scss

    1. You can then just use one class in your markup <button class="Button--error"> and get the common & specific styles you want. It’s a really powerful concept, but the implementation has some edge cases & pitfalls that you should be aware of. A great summary of those issues and links to further reading is available here, thanks to Hugo Giraudel.

      Some notes worth a read on SASS and @extends

  30. Sep 2015
    1. Some interesting slides on CSS styling performance on GitHub, particularly focusing on their diff pages.

      Several slides have direct references to WebKit internals explaining the impact on rule resolution performance.

      Mentions a useful tool for understanding CSS selector performance implications, css explain

    1. Nesting for BEM—or any other flavor CSS architecture—is helpful at first, but comes as a cost.

      Useful note on the pros and cons of using SCSS to simplify writing BEM-esque styles in CSS.

      The advice here is to just write out class names in full to make grepping easier.

    1. Atomic CSS (ACSS)

      So this is essentially inline styles, but done using the 'class' attribute rather than 'style', where one class is created per unique declaration. cf' @vjeux's presentation on inline styles

    1. LESS (and now SASS as well) allow to use & within a single class name. There is no strict requirements on what should be the symbols before and after &. Thus, you can produce simple selectors instead of cascades.

      This is the approach I've started to take for H

    1. Harry Roberts also has a brilliant system for ensuring all CSS keeps to the right naming convention: he lints his CSS using scss-lint to ensure all team members stick to the convention correctly. As Harry put it, “It’s all well and good telling the team to use BEM, but it’s important to police it as well.

      Recommendation for a useful tool to enforce CSS class naming consistency

    2. In Yandex we usually separate styles per block, its modifiers, its elements and for their modifiers. But in reality it is very hard to support all these separations. That’s why in pet projects I and ex-Yandexers support a one-file-per-block structure

      One "block" === a "component" in other terminology - as explained on the main BEM site, so this translates to one-file per component

    1. This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we daren't touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS' globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don't know what things do any more. People daren't make changes because they don't know how far reaching the effects will be.
    1. To create a mixin you use the @mixin directive and give it a name. We've named our mixin border-radius. We're also using the variable $radius inside the parentheses so we can pass in a radius of whatever we want. After you create your mixin, you can then use it as a CSS declaration starting with @include followed by the name of the mixin. When your CSS is generated it'll look like this

      This particular example would be better replaced with a post-processor like autoprefixer

  31. Feb 2014