701 Matching Annotations
  1. Sep 2019
  2. 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.
  3. Apr 2019
    1. /* Changes the font size on the titles of Kinds */section.response > header {  font-size: 20px;}

      I really like the Kinds plugin, but should look into some of these possibilities.

  4. 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

    1. So I won't be covering the out of date IE syntax

      See other resources for this, among which: https://css-tricks.com/css-grid-in-ie-debunking-common-ie-grid-misconceptions/ and cheer up! IE support for CSS Grid is good and definitely work-able!

  5. Jan 2019
  6. Dec 2018
    1. 关系选择器

      1. 后代选择器 - adjacent - a b
      2. 子代选择器 - children - a > b
      3. 兄弟选择器 - sibling - a ~ b
      4. 相邻兄弟选择器 - adjacent sibling - a + b

      重要:关系选择器从右向左解析,因此要注意选择的边界

  7. Oct 2018
    1. .truncate { width: 250px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; }
  8. 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"); });
  9. 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
  10. Sep 2017
  11. Aug 2017
    1. The term mobile first encourages us to think in terms of device. But the web isn’t a set of devices. The web is a continuum of edgelessness. That’s the coolest sentence I’ve ever written.
  12. 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)

  13. Mar 2017
    1. truth is, there isn’t a better system – both flexbox and the CSS grid are good at different things and should be used together, not as alternatives to one another.

      This is a great post to keep as a reference.

    2. 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

  14. 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.

  15. Oct 2016
  16. Sep 2016
    1. Note: A future level of CSS may introduce ways to create custom highlight pseudo-elements.

      Oh my god, yes please!

  17. Jul 2016
    1. Despite the misgivings I have about the way the whole site works, the styling code is simple and uses a pretty similar approach to what has been proposed for Hypothesis

    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>
    1. #registration

      same as CSS, # refers to element ID

    2. input

      which child element do you want to manipulate, separated with a space

    3. [name=confirmation]

      like an associative array, looking for where the attribute name = confirmation

  18. 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.

  19. Mar 2016
  20. 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.

  21. 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.

  22. Dec 2015
  23. edwardtufte.github.io edwardtufte.github.io
    1. Tufte’s style is known for its simplicity, extensive use of sidenotes, tight integration of graphics with text, and carefully chosen typography.

      CSS style dla pięknych artykółów

  24. Oct 2015
    1. Links to a ton of style guides for different sites - possibly a very useful reference for H

    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

    2. Documentation on what changed in the Bootstrap 4 Alpha, possibly a useful reference for CSS best practices in 2015.

    1. Note that we currently are using a universal selector reset in reset.scss in H which changes the default box-sizing model.

    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

    2. Article introducing CSS modules

  25. 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.

    2. This post and a few others on the same blog contain some useful notes about experiences with CSS at GitHub

    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. There isn’t much we can do to change how CSS works

      That's unfortunately defeatist.

    1. Useful article on how to apply BEM styling with SCSS as something to point people to.

    2. 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. “Use long, descriptive class names over short names that don’t document themselves.”

      And also when you have only crude tools for refactoring, this makes it easier to refactor CSS class names.

    3. 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

    4. Some useful notes on experiences with BEM-style CSS at scale

    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. The patterns described here appear to be what the H code is following at the moment, but note this comment where the author notes that they since abandoned the approach in favor of more pure modular CSS.

    1. Recommendations for how to structure blocks (ie. components) which fits in well with recommendations about how to structure components from other places.

    1. Potentially useful article discussing applying various methodologies for structuring CSS, particular in the context of React but likely relevant for any component-orientated system.

    1. This is an interesting history of web app and specifically component / styling development at Yandex and the evolution of the BEM methodology.

    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

    1. So to sum up: It should be an active design choice whether you want to enable users to change the font size independently to parts of or all layout and graphics. If so, pixels will probably not be your friend. If not, I’d say it’s mainly a matter of personal taste and/or project.

      This is good guidance on when/whether to use em vs. px sizing

    2. Useful article giving an overview of the history of how browser zooming affected CSS units.

      Makes a strong overall recommendation to use px almost everywhere, except where component size elements should specifically relate to their font.

    3. In version 7 of internet explorer that was released in October 2006 there was a very prominent zoom icon on the bottom right of the browser window. And guess what… The zoom function was just modifying the CSS reference pixel in the browsers CSS rendering engine!

      This is a useful resource on the history of zooming and accessibility in browsers.

      See also this argument

    1. This is not true nowadays. Pressing Ctrl+ and Ctrl- in any modern browser will scale the pixel values as well. It has been like this for a while now.
  26. Feb 2014