Preface

There is always sometimes when I ran into a problem and I was stuck in there. After problems solved, I watched back and thought maybe I can fix the problem alone or it shouldn’t take me so much time to work it out. So, I decided to write something about how to debug with a more efficient way.

Steps

Calm down first

Are you beginning to sweat now? Take a walk if you are and forget about the origin thought.

Try to figure out what the question you are facing

Problems which are in a big project

Well, I hate this but I still meet this in some cases.

At present, I am trying to extract the problem from the big project and reproduce it in a demo which is as minimal as possible. Then, I will try to figure out what the problem I am actually facing with. After all, it’s easier to debug in a minimal demo than a big project. Then, fix the demo and fix the project.

Sometimes the problems can’t be or are not easy to be extracted. In that case, I would try to disable other functions which might complicate the problems to make the problems easier to fix.

Problems which are out of control

If the error is out of your control, for example, you are working with something you basically have no idea, you had better pay attention to the error information. Then find the document and search for something about the error information.

It is quite common to encounter a new problem when we are using a frame which we don’t know much about it. If that happens, the quickest way is to find the document and see if the way we use is not right.

Problems seem familiar

If you know something about your error, for example, you are running a demo which doesn’t behave as you expected, maybe you should stop and ask yourself a few questions:

• What is my expected output?

• Why should the demo behave like that?

In this way, you might say that it should behave like that because the specs said that it should ….. It doesn’t matter if you don’t remember the details of the specs. In this case, you should go to check the part of the specs and read the specs carefully again to see if it really defines the behavior you expected. And I still suggest you reading the specs again even that you remember the details.

Don’t tell me you don’t know where the specs is because this shouldn’t happen. Or if it really happens, it is better for you to find the specs as soon as possible.

Usually, you will find that you missed something in the specs or just misunderstand the specs or the specs just didn’t define the specific behavior.

However, sometimes you are totally right after reading the specs. In this case, I think it’s time to ask in the community like Stackoverflow or just ask the specs working group. Before asking, you had better know something about how to ask.

Ending

Anyway, the last way is google and I will update when I figure out something new.

Preface

There is a lot of tutorials teaching you build your own blog by github pages with url like https://username.github.io.

Well, I am not going to do that. Why would I have to build blog on my main site rather than https://username.github.io/blog?

That is what I’m going to do! Build a blog under main site so that it wouldn’t take over the main site. Suppose that you have already known something about npm and git or Github.

Steps

• Install hexo and hexo-cli

npm install -g hexo-cli
npm install -g hexo

• Create your blog folder with no file, and get into the folder(for example, my blog folder is blog).

cd blog

• Initialize hexo and install dependencies

hexo init
npm install

Normally, dependencies will be installed automatically

• Try to run it locally

hexo s -g

Normally, you will see:

• Open the browser with the url in the above screenshot:

You can change the theme if you don’t like it. However that is not the point of this article. You can do it according to the docs in hexo.

• Also, if we want to deploy it on github, we have to install hexo-deployer-git according to docs.

npm install hexo-deployer-git --save

• Suppose that you already have a repository on github. For example, the name is blog and url is https://github.com/username/blog. Then find the _config.yml file in the folder. Open it update the url and root as follows:

url: https://github.com/username/blog
root: /blog/

Also, update deploy like this:

deploy:
  type: git
  repo: https://github.com/username/blog
  branch: master

Well, I have to warn you that
and the space before word type, repo and branchshould be blank space not tab. Otherwise, you will get error about your indentation.

• Now, try to deploy it on github:

hexo d -g

Open your repository url like https://github.com/username/blog and you will find there is a few files and folders. Remember to clear cash with ctrl+shift+delete if you just pushed.

• Suppose that you already make the repository become a github page. Then, you can open your page url like: https://username.github.io/blog/. You will see what you see locally last time.

Default settings

some stuff should be done by default which hexo didn’t:

• Generate .deploy_git/categories folder when deployed. This might be done by default.

npm install hexo-generator-category --save

• Generate index.md under folder source/categories and source/tags

hexo new page categories
hexo new page tags

Also, need to add type: tags and type: categories in the above corresponding file index.md. It will help you generate index.html under folder .deploy_git/categories and .deploy_git/tags when deployed.

Update

• I just found that default hexo-renderer-marked didn’t work with some markdown syntax like .deploy_git/categories. So, I change my markdown parser;

npm uninstall hexo-renderer-marked  --save
npm install hexo-renderer-markdown-it  --save

• Before deploying, you had better remove the public and .deploy_git folder because they won’t be rewritten sometimes.

• Above operation works well if there is no image in the markdown. However, if there is an image, for example:

The path for the image will be resolved incorrectly. In consistent with above case, the correct path should be https://username.github.io/blog/images/20180520102405.png while what we got is like https://username.github.io/blog/2018/05/20/images/20180520101721.png.So, we need to modify src to get a new url.

window.addEventListener('error', windowErrorCb, { capture: true }, true)
document.addEventListener(
  'DOMContentLoaded',
  refreshImgUrl,
  { capture: true },
  true
)
function windowErrorCb(event) {
  let target = event.target
  imgErrorCb()
  function imgErrorCb() {
    let isImgErrorHandled = target.hasAttribute('data-src-error')
    let isImgPathMatch =
      target.tagName.toLowerCase() === 'img' &&
      target.src.match(/\/images\/[^/]*?\d{10,20}[^/]*$/)

    if (isImgPathMatch && !isImgErrorHandled) {
      target.src = 'https://xianshenglu.github.io/blog' + isImgPathMatch[0]
      target.setAttribute('data-src-error', 'handled')
    }
  }
  return true
}

function refreshImgUrl(event) {
  let isImgPathMatchReg = /\/images\/[^/]*?\d{10,20}[^/]*$/
  $('img')
    .toArray()
    .forEach(img => {
      if (img.src.match(isImgPathMatchReg)) {
        img.src = img.src
      }
    })
}

To solve question above, you can put the code above in the bottom of the file theme/next/source/js/src/motion.js which should be changed according to your theme and image’s path. Actually, you can put the code in any js file as long as you are sure that it will be loaded.

Ending

Well, the main settings have already finished. And if you want to set the theme or other things, go check the docs.

Preface

As we all know, when we set background-color in block-level non-replaced elements, the height of background-color is equal to border-top+padding-top+height+padding-bottom+border-bottom according to box-model which is very clear.

Question

However, things get weird when we set background-color to inline non-replaced element because height doesn’t apply to the element. For example:

<div class="inline">
  inline non-replaced element
</div>

* {
  margin: 0;
  padding: 0;
}
html {
  font-family: Microsoft YaHei;
  font-size: 40px;
}
.inline {
  display: inline;
  background-color: pink;
  line-height: 2;
}

So, here is the question,

• Assume there is no margin and padding,how much is the size of the background-color area which is also the content area ?any rules?

And here is the answer I figured out:

• It depends.

Then we are going to talk a lot about how it depends.

If we measured the direction as the screenshot above ,we can get some data below, called Case A :

• font-size:40px
• background-color’s height : about 50px
• top/bottom space : about 15px

May be you thought that those data should be like these, called Case B :

• font-size:40px
• background-color’s height : about 40px
• top/bottom space : about 20px, equals to half-leading

It seems Case B is more reasonable.

However, the fact is that Case A is applied until Chrome-66.

Anyway, line-height is definitive, always 80px.

After reading 10.6.1 Inline, non-replaced elements in CSS2.1 and SO, I think the point is below:

The ‘height’ property does not apply. The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font.

(The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the ‘line-height’, but leads to glyphs painting outside their content area.)

According to the specification above, I think that Case B means

A UA use the em-box which would ensure authors can control background styling relative to the ‘line-height’, but leads to glyphs painting outside their content area.

while Case A means

A UA use the maximum ascender and descender of the font which would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts.

Then, I try to prove it with different fonts which will lead differently sized boxes according to specification above.

For example, change font-familyfrom Microsoft YaHeitoGeorgia:

<div class="inline">inline non-replaced element <br />sss</div>

* {
  margin: 0;
  padding: 0;
}
html {
  font-size: 40px;
  font-family: Georgia;
}
.inline {
  display: inline;
  background-color: pink;
  line-height: 2;
}

As you can see ,these data becomes:

• font-size:40px
• background-color’s height : about 46px
• top space : about 15px
• bottom space: about 19px

Conclusion

So, precisely, assuming that there is no margin and padding,we can say that background-color’s height of inline non-replaced element is

• determined by font-size
• and modified partially by font-family which depends on the rules UA takes.

And also the area outside of the background-color area isn’t equal to half-leading.

Reference:

Inline elements and line-height

Deep dive CSS: font metrics, line-height and vertical-align

这个 div 的 10px 是哪里来的能帮我看一下吗？