1.第一步选择你喜欢的图片

2.第二步点击购物车添加到一个指定的项目

3.下载添加好的文件

4.解压文件

5.编辑文件iconfont.css

原始

修改后

最后将编辑过的css文件直接引入即可,其他文件无需引入,demo_index.html是一个例子,打开它就可以看如何通过css使用字体

 

给父div加一个 overflow:hidden 属性即可。如下:

一、单字段(nick_name)

1、查出所有有重复记录的所有记录

2、查出有重复记录的各个记录组中id最大的记录

3、查出多余的记录,不查出id最小的记录

4、删除多余的重复记录,只保留id最小的记录

二、多字段(nick_name,password)

1、查出所有有重复记录的记录

2、查出有重复记录的各个记录组中id最大的记录

3、查出各个重复记录组中多余的记录数据,不查出id最小的一条

4、删除多余的重复记录,只保留id最小的记录

1.安装NVM

2.添加到脚本启动器中 ~/.bash_profile

3.测试一下

4.NVM的基本使用

5.当执行完成nvm use 8.16.0 可以使用下方命令进行测试

 

根据你的产品特点,进行两种不同的设计,
根据你的设计需求,选择合适的技术方案

A与B不是硬币的正反面,它们为了解决同一个问题而生,它们是同一种思想的延伸。

移动和桌面设计的差别远不止是布局问题。只要有足够的编程量,这些差别是可以通过响应式设计来解决的。事实上,你可以认为如果一种设计不能兼顾两种平台的主要差别,就不能算是合格的响应式设计。但是,如果确实想要处理好平台间的所有差异,我们就回到了原点:进行两种不同的设计。

——《Mobile Usability》(《贴心设计 打造高可用性的移动产品》)

那么究竟响应式设计适合哪些场景?

正如我们经常看到的那样,很多中小型企业,个人博客,创业公司,开源项目,小型网店,艺术家,画家,音乐家,甚至是政府和学校,都使用响应式技术,来搭建他们的网站。这些页面的特点一般都是访问者和网站的交互很少,仅仅用于信息展示和获取以及点个赞什么的。需要写的兼容性代码很少,非常适合做成响应式。

 

响应式设计不适合哪些场景呢?

而像淘宝,京东,还有其他的重交互性系统,则不大那么适合使用响应式技术。《响应式 Web 设计》一书中提到,响应式设计应该以移动用户的体验优先。在进行功能性设计的时候,需要优先考虑移动端的用户体验,然后才能考虑计算机端的用户体验。毕竟计算机的屏幕,比手机要大很多。产品经理往往要考虑,如何物尽其用并且堆砌更多的功能,所以响应式设计就不再是一个明智的选择。当然,这里有一个很重要的前提,您的技术团队,将需要维护两套代码,和两套基本不一致的系统。这对小型创业公司简直就是一个灾难。

 

对于响应式设计技术理解的误区

有很多朋友还说,响应式设计,由于需要同时支持计算机和手机,所以代码的执行效率比较低。也有的朋友说,响应式技术制作的网站,将比普通网站需要加载更多的样式和脚本,所以打开速度比较慢。这么说的朋友,一般有两类人。一类人是,认为慢5%,也算慢的人;另外一类人是,听第一类人说慢,就认为慢了。起飞页作为国内使用响应式技术比较多的一家公司,专门的做过一些内部测试。在去掉了,响应式样式和脚本之后,页面的加载速度,确实提高了,但仅仅提高了3%到5%。相对于响应式带来的各种好处来说,这点性能上的开销,几乎可以忽略不计。

 

要不要使用响应式?

对于初创企业,如果希望投入较小的时间和精力,就可以让自己的网站在手机以及平板电脑上被使用,响应式技术完全是最佳解决方案。如果您的企业成长到了一定的规模,并且希望,这手机上来点不一样的东西,那么专门的移动系统,也是一个不错的选择哦。顺便说一下,其实百度和阿里,腾讯,小米,知乎,很多大家都耳熟能详的公司,都在不同的产品中,使用非常多的响应式技术。可见,即使是财大气粗的大公司,也并不是都能支撑得住独立移动系统的开销。套用一句老话作为结束,作为产品经理,我们需要能够找到用户体验和构建成本的平衡点。

 

有读者问,在手机上打开淘宝和百度的网站,发现地址前面都有个“m”,例如:m.taobao.com, m.baidu.com。要是响应式技术像你说的那么神,为什么这些大公司不直接使用响应式技术构建网站?这样不是更省钱么?

其实无论是什么解决方案,我们先来看看我们想要解决的问题:

“屏幕尺寸越来越多,不同设备的交互特质也有着巨大的差别,我们希望我们的网站能够在移动手机、平板、桌面电脑,在键鼠、触摸、无障碍设备上都有优秀的用户体验。所以,我们需要网站的用户界面在不同的平台上有所不同。”

那怎么做呢,一个解决方案应运而生:

  • 响应式设计 (Responsive Web design)

狭义上,我们把主要依靠前端 CSS (包括 Media Query 媒体查询,百分比流式布局,网格与Typography系统……)来对各种屏幕尺寸进行响应的做法,称之为响应式布局,又称作自适应网页设计,或者弹性设计。

这种主要依靠CSS的方案有很多优点,比如:

    • 设计元素很容易被复用,设计成本低
    • 前端只需要维护一套CSS代码,维护成本
    • 桌面端与移动端的设计十分接近,令用户感到“熟悉”
    • 不需要任何服务器端的支持
    • 与业务耦合程度低,复用程度高( 以至于 Bootstrap、Foundation 等一干框架都跟进了这个解决方案 )

但问题也很明显,比如:

    • 设计需求复杂时,前端的开发成本没有任何减轻
    • 无论是针对桌面还是移动的CSS代码(甚至图片资源文件)都会被同等的下载到客户端(没有考虑移动端的网络优化
    • 如果JS不写两套,桌面端的交互和移动端的交互很难针对平台作出差异

如果你的移动用户对网站所有的功能和内容有着与桌面用户同等的需求,比如 新闻、报纸(媒体类)网站,或者活动、专题页等 偏重信息传达而轻交互 的网站,那么这个解决方案其实恰到好处:
触摸屏优化(胖手指)、减少次要信息…… 这些通过 CSS 解决就够了。

但是,如果我想要做更多的 「移动化设计」,比如 减少信息层级、增强手势操作、让网页更接近一个Native App ?

好吧,为了更复杂的需求,为了我们的网站能更牛逼的 「响应」 各个平台,
又有了这些解决方案:

  • 服务器端(后端):
    • RESS (Responsive Web Design with Server Side Components)通过服务器端组件的响应式网页设计

提倡 RESS 的人认为:基于前端 CSS 的响应式方案只是一种妥协:
“ UI 只是在很被动的进行「调整」,而不能真正达到各个平台的最优。好的设计应该达到「这个设备该有的体验」(Device Experiences)。 ”

Device Experiences :A device experience is defined by how a device is most commonly used and the technical capabilities or limitations it possesses.

RESS 的本质还是服务器端动态的生成,返回 HTML、JS、CSS、图像等资源文件,但是只使用同一个 URL 就可以提供给移动端定制化更强的网页,同时还大大节省了网络资源。

  • 前端(主要是JS),比如:
    • 在 JavaScript 中实现两套逻辑,分别兼容键鼠、触摸设备
    • 通过 UA、特性检测 在前端做设备判断,对资源进行异步加载,渲染不同模版
    • 通过 特性检测 在前端做设备判断,使用不同的业务逻辑
    • 前端的模块化也可以帮助解决这个问题,比如针对不同的平台加载不同的模块
    • ……

这下,我们的网站可以更牛逼的 “响应” 各个平台了。 (对,我还是称之为响应:这的确还是在“响应”啊 ,不是吗?)

但是等下……
后端开发成本上去了,前端开发成本也上去了,配合着估计产品、设计资源也都上去了,那我们为什么不干脆把 移动设备网站 和 桌面设备网站 分开呢!?

是啊,如果你的需求真的都到这一步了,你的移动网站也应该可以被称作 WebApp 了。这种时候,把移动设备网站彻底分开或许真的是更好的选择。

开发资源如此充足,你还可以让专门的团队来维护移动端的网站。 (嗯,BAT 就是这么干的)

于是又一个概念来了:

  • 独立的移动版网站 (按题主的话来说:手机和PC端分开来写)

不过,它有那么独立么?
我们知道,我们访问网站是通过 URL 来访问的。
将移动网站 和 桌面网站 分开,如果不使用 RESS 技术,往往也就意味着要维护两个URL(不同的二级域名)
难道我们要让所有桌面用户自觉访问 taobao.com ,所有 移动用户 都自觉访问 m.taobao.com ?
不可能吧 = =。

于是,我们还是得依靠前端或服务器端的一次 “响应”(设备检测),做 URL 重定向,才能将不同设备的用户带到那个为他们准备的网站。

所以其实在我看来,手机和PC端分开来写,只是 狭义响应式设计 的一种发展和延伸罢了。他们的界限没有,也并不需要那么清晰。

就如开题所引用的:

事实上,你可以认为如果一种设计不能兼顾两种平台的主要差别,就不能算是合格的响应式设计。

“而无论是用什么解决方案。” —— 这句是我补的。

故我的结论是:

这不是一个二选一的问题,而是选择一个合适的度(你的桌面版本代码与移动版本代码分离、耦合的程度)

而这个度,则是由你的设计需求决定的。
而我们的需求原点其实也很简单:

根据你的产品特点,进行两种不同的设计”。

此处为thinkphp加javascrip混编

1.编辑\app\config.php的配置文件

2.编辑simplewind/cmf/common.php 文件

跨源共享标准需要浏览器和服务端共同配合才能完成,目前浏览器厂商已经可以将请求部分自动完成,所以跨源资源访问的重点还是在于服务器端。

下面列出一些标准中可用的响应头和请求头。

Response Header

  • Access-Control-Allow-Origin : 指明哪些请求源被允许访问资源,值可以为 “*”,”null”,或者单个源地址。
  • Access-Control-Allow-Credentials : 指明当请求中省略 creadentials 标识时响应是否暴露。对于预请求来说,它表明实际的请求中可以包含用户凭证。
  • Access-Control-Expose-Headers : 指明哪些头信息可以安全的暴露给 CORS API 规范的 API。
  • Access-Control-Max-Age : 指明预请求可以在预请求缓存中存放多久。
  • Access-Control-Allow-Methods : 对于预请求来说,哪些请求方式可以用于实际的请求。
  • Access-Control-Allow-Headers : 对于预请求来说,指明了哪些头信息可以用于实际的请求中。
  • Origin : 指明预请求或者跨域请求的来源。
  • Access-Control-Request-Method : 对于预请求来说,指明哪些预请求中的请求方式可以被用在实际的请求中。
  • Access-Control-Request-Headers : 指明预请求中的哪些头信息可以用于实际的请求中。

Request Header

  • Origin : 表明发送请求或预请求的来源。
  • Access-Control-Request-Method : 在发送预请求时带该请求头,表明实际的请求将使用的请求方式。
  • Access-Control-Request-Headers : 在发送预请求时带有该请求头,表明实际的请求将携带的请求头。

中间件

在 Laravel 中允许跨域请求,我们可以在app/Http/Middleware/文件夹下构建一个追加响应的中间件Cors.php,用来添加专门处理跨域的请求的响应头:

使用中间件

在app/Http/Kernel.php文件中protected $routeMiddleware处增加’cors’ => \App\Http\Middleware\Cors::class,。

kernel文件

需要跨域请求的路由:

其中有以下需要注意的地方:

  • 对于跨域访问并需要伴随认证信息的请求,需要在 XMLHttpRequest 实例中指定 withCredentials 为 true。
  • 这个中间件你可以根据自己的需求进行构建,如果需要在请求中伴随认证信息(包含 cookie,session)那么你就需要指定 Access-Control-Allow-Credentials 为 true, 因为对于预请求来说如果你未指定该响应头,那么浏览器会直接忽略该响应。
  • 在响应中指定 Access-Control-Allow-Credentials 为 true 时,Access-Control-Allow-Origin 不能指定为 *
  • 后置中间件只有在正常响应时才会被追加响应头,而如果出现异常,这时响应是不会经过中间件的。