分类目录归档:Html5

Vue+Webpack打包后background-image无法正常显示

1、背景:正常情况下打包后的页面都是基于在网站根目录下运行,原则上不会出现这种情况,但如果项目放在网站的二级目录或本地运行(官方不建议本地运行项目,可能涉及到网络请求的问题)
2、基于项目在二级目录下运行,即打开时需要输入http://xxx.xxx.xxx/xxx,而不是直接http://xxx.xxx.xxx这种
3、二级目录下打包后的项目要能正常运行,需要在config/index.js中

build:{
   ....
   assetsPublicPath: '/'
   ....
}

修改成:assetsPublicPath: ‘./’
4、问题来了,因为是相对路径,所以在css中写的url是相对当前这个css文件的,所以打包后的背景图片url如果为static/img/xxx.jpg,结果解析出来的路径是xxxxx/static/css/static/img/xxx.jpg,图片当然无法正常显示了;
5、也许有些人会发现,为什么有些图片是正常的?好像并不是都不行啊,注意了,那些没有问题的图片看下路径是不是加载的base64格式?!
6、在webpack.base.conf.js中会有这么一段

      {
        test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('img/[name].[hash:7].[ext]')
        }
      },

这里的意思是说,小于10K的图片资源会在打包时直接转成base64,你可以把这个值放大,大于你的背景图,这样也可以解决
7、还有另外一个办法,在build/utils.js文件中找到下面这一段

    // Extract CSS when that option is specified
    // (which is the case during production build)
    if (options.extract) {
      return ExtractTextPlugin.extract({
        use: loaders,
        fallback: 'vue-style-loader'
      })
    } else {
      return ['vue-style-loader'].concat(loaders)
    }
  }

修改成:

    // Extract CSS when that option is specified
    // (which is the case during production build)
    if (options.extract) {
      return ExtractTextPlugin.extract({
        use: loaders,
        fallback: 'vue-style-loader',
        publicPath: '../../'
      })
    } else {
      return ['vue-style-loader'].concat(loaders)
    }
  }

只是加了一行publicPath: ‘../../’,这样一来样式文件会相对于根目录加载,这种方式也是有局限性的,为什么可以写两个../就行了呢?因为我们的img与css都是放在static目录下的二级目录,所以两个../刚好到static同级,如果不是则会出错的哦,注意就行!

参考链接:https://segmentfault.com/q/1010000009700735

Vue项目中当前比较好的移动端UI库–vux

官方网址:https://vux.li

1.安装vux

npm install vux --save

2.安装vux-loader(vux2必须结合vux-loader使用)

npm install vux-loader --save-dev

请在build/webpack.base.conf.js里参照如下代码进行配置:

1
2
3
4
5
6
7
const vuxLoader = require('vux-loader')
// 官方文档这句话有点坑,基础不好的请注意,这里的意思是说将原来文件module.exports = {....}
// 替换成const webpackConfig = {....},没有"originalConfig"这个变量
const webpackConfig = originalConfig // 原来的 module.exports 代码赋值给变量 webpackConfig
module.exports = vuxLoader.merge(webpackConfig, {
  plugins: ['vux-ui']
})

3.安装less-loader以正确编译less源码

npm install less less-loader --save-dev

安装完成记得在webpack.base.conf.js里做如下配置,在extensions里加入less

1
2
3
4
5
6
7
resolve: {
    extensions: ['.js', '.vue', '.json', 'less'],
    alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src'),
    }
  }

4、安装 yaml-loader 以正确进行语言文件读取

npm install yaml-loader --save-dev

5、引入 reset.less,默认样式不包含reset,并且部分用户自己有一套reset样式,因此需要在App.vue进行手动引入

1
2
3
<style lang="less">
@import '~vux/src/styles/reset.less';
</style>

为什么所有浏览器的userAgent都带Mozilla

  最早的时候有一个浏览器叫NCSA Mosaic,把自己标称为NCSA_Mosaic/2.0 (Windows 3.1),它支持文字显示的同时还支持图片,于是Web开始好玩起来。

  然后出现了一个新的网页浏览器,“Mozilla”,其实就是“Mosaic终结者”的意思,这搞的Mosaic很不爽,(毕竟Mosaic出道早,江湖老),新浏览器最后正式公布的名称是Netscape,它把自己标称为Mozilla/1.0 (Win3.1),更好玩了。Netscape支持框架显示,后来框架在大家中间流行起来了,但Mosaic不支持框架啊,于是伟大的“用户代-理人探测”技术出现了,如果是“Mozilla”,那就发给支持框架的页面,至于其他的浏览器,则发给不含框架的页面。

  Netscape想逗Microsoft玩儿,把Windows叫做“几乎不曾做过调试的设备驱动器”,后者很恼火。Microsoft于是推出了自己的 网页浏览器,叫做Internet Explorer,希望它能成为“Netscape终结者”。Internet Explorer也支持框架,但它不是Mozilla啊,所以没人给它发送带有框架的页面。Microsoft慢慢烦躁起来,不再寄希望于网站管理员逐渐 认识IE并给它发框架,而是宣称自己是“兼容Mozilla”的,开始模仿Netscape,把自己标称为Mozilla/1.22 (compatible; MSIE 2.0; Windows 95),这样Internet Explorer也能收到框架了,整个Microsoft狂喜,但网站管理员开始有点被搞糊涂了。

  Microsoft把IE和Windows一起卖,并且把产品也弄得比Netscape更好了,拉开了第一场浏览器之战。结果和大家知道的一样,Netscape被干掉了,Microsoft大胜、大喜。但是后来Netscape以Mozilla的新名称重生了,构造了Gecko,标称其为Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826,Gecko属于渲染引擎,表现优异。Mozilla开发了Firefox,标称为Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0,并且Firefox表现也非常优秀。Gecko扩张迅速,一些浏览器使用了它的代码并标称为Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040825 Camino/0.8.1 ,这是一个,还有Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.8) Gecko/20071008 SeaMonkey/1.0,另一个,它们都伪装成Mozilla,同时也都是基于Gecko支持的。

  Gecko表现优秀,IE则很差劲,于是身份甄别再次发生,输送给Gecko的是设计良好的网页代码,其他浏览器就没有这个待遇了。Linux的跟随者很伤心,因为他们创建了基于KHTML引擎支持的Konqueror,但却不会被输送好代码,虽然他们自己认为KHTML和Gecko一样优秀,于是Konquerer开始伪装自己“像Gecko”那样以得到好的网页,并标称自己为Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko),这个世界更让人困惑了。 继续阅读