web前端

对于未来chrome80 samesite问题的兼容解决方案

未来chrome80会默认(SameSite: lax)在跨域请求的情况下不允许跨域携带cookie给后端,导致所有跨域场景下使用cookie进行鉴权的服务会受到影响。
网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。
但是设置了SameSite为None, 很难保证在非chrome浏览器上一定是兼容的,所以基于兼容性考虑有两个方案:
1.采用两套cookie 例如原cookie中已经种入了session-id=xxxxx,可以维持不变,再额外种入另一个cookie session-id-2=xxxxx同时设置特性SameSite为none secure: true。这样可以兼容新旧版的所有浏览器。这样就要求后端取得时候判断session-id不存在,再取cookie session-id-2的值
2.JWT方案,统一把token放在header的authorization,就不存在跨域携带cookie的困扰了
第一个方案主要适配在于后端,前端基本不需要变动,第二个方案需要前后端做一定的改造,视情况而定

    

Head标签里面的dns-prefetch,preconnect,prefetch和prerender

开始

今天突然心血来潮想起前端性能优化的问题,这基本是老生常谈的事情了,面试随便都能说上几个,但是还是有点疑问:就是Head标签了,记忆中Head可是藏龙卧虎,各种技能都有,当然这些不可能都一一记住,太伤脑细胞了,于是打开神奇的Github,来到这个 HEAD项目,翻一翻就会看到今天的主角dns-prefetch,preconnect,prefetch和prerender兄弟了,究竟他们有何区别,是怎样的一家人尼。

    

CSS 定位详解

CSS 有两个最重要的基本属性,前端开发必须掌握:display 和 position

display属性指定网页的布局。两个重要的布局,我已经介绍过了:弹性布局flex网格布局grid

本文介绍非常有用的position属性。我希望通过10分钟的阅读,帮助大家轻松掌握网页定位,说清楚浏览器如何计算网页元素的位置,尤其是新引进的sticky定位。

 

    

最标准的系统字体规范font-family

最标准的系统字体规范font-family

注意系统默认字体和浏览器默认字体这个差别。

直接提供方案:

font: 14px/1.6 
/*西文*/-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Ubuntu,Helvetica Neue,Helvetica,Arial,
/*中文*/PingFang SC,Hiragino Sans GB,Microsoft YaHei UI,Microsoft YaHei,Source Han Sans CN,sans-serif;

这些都是些什么字体?

1、-apple-system, BlinkMacSystemFont: