检查肠胃挂什么科
|
tpp是什么意思
|
玉米淀粉是什么
|
为什么叫中国
|
斯里兰卡属于什么国家
|
梦到结婚是什么预兆
|
蜜饯是什么意思
|
生死劫是什么意思
|
症是什么意思
|
双开什么意思
|
麦芯粉是什么面粉
|
圣诞礼物什么时候送
|
血小板偏低是什么意思
|
男性感染支原体有什么症状
|
面霜是干什么用的
|
经常打飞机有什么危害
|
无私是什么意思
|
9月1号什么星座
|
心肌桥是什么意思
|
喘不上气吃什么药见效
|
天蝎座和什么星座最配
|
screenx影厅是什么
|
消肿吃什么食物好
|
燊什么意思
|
无什么无什么
|
夏天为什么热
|
妈妈是什么意思呢
|
秋葵有什么好处
|
羊水栓塞是什么意思
|
路上行人匆匆过是什么歌
|
七月初七是什么生肖
|
五粮液什么香型
|
转氨酶高吃什么药
|
梦见女鬼是什么意思
|
阴道镜是检查什么的
|
业报是什么意思
|
淋病有什么症状
|
过敏性结膜炎用什么眼药水
|
什么啤酒劲最大
|
长情是什么意思
|
癫痫病是什么原因引起的
|
年少轻狂是什么意思
|
讲义气是什么意思
|
心衰用什么药
|
fwb是什么意思
|
九月三日是什么日子
|
枭神夺食会发生什么
|
为什么额头反复长痘痘
|
天津有什么玩的
|
工作性质是什么意思
|
为什么种牙那么贵
|
晚上8点半是什么时辰
|
吃什么解腻
|
头三个月保胎喝什么汤
|
手脚发烫是什么原因造成的
|
守字五行属什么
|
为什么头出汗特别多
|
paco2是什么意思
|
错峰是什么意思
|
初一不能做什么
|
食管有烧灼感什么原因
|
城隍爷是什么神
|
梅花是什么颜色的
|
需要一半留下一半是什么字
|
疝气是什么病怎样治疗
|
阴阳两虚吃什么中成药
|
妈妈生日送什么礼物
|
肠胃炎喝什么药
|
中心性肥胖什么意思
|
金钱能买来什么但买不来什么
|
打下手什么意思
|
尿白细胞定量高是什么意思
|
中暑喝什么好
|
小孩趴着睡觉是什么原因
|
什么时候补钙最佳时间
|
市监狱长是什么级别
|
春指什么生肖
|
早搏的症状是什么表现
|
八月十一号是什么星座
|
芋头什么时候种植最好
|
脑梗什么意思
|
尿道口红肿是什么原因
|
世界上最高的塔是什么塔
|
为什么会脱发
|
被蜱虫咬了挂什么科
|
哀莫大于心死什么意思
|
昕五行属什么
|
心电图t波改变是什么意思
|
子宫内膜炎症有什么症状
|
七月七是什么日子
|
催乳素是什么
|
开普拉多的都是什么人
|
普惠性幼儿园是什么意思
|
曹操是个什么样的人
|
眼睛浮肿是什么原因
|
双子座的幸运花是什么
|
七月十五是什么节
|
疱疹性咽峡炎是什么引起的
|
人造棉是什么面料
|
风光秀丽的什么
|
口腔溃疡吃什么好的快
|
康桑密达是什么意思
|
肠鸣是什么原因
|
上海玉佛寺求什么最灵验
|
为什么爱放屁
|
癌胚抗原高是什么意思
|
农历今天属什么
|
海淘是什么意思啊
|
2.18是什么星座
|
你喜欢什么
|
补办医保卡需要什么资料
|
腕管综合症吃什么药
|
东风是什么意思
|
什么是蛀牙
|
力排众议是什么意思
|
吃什么缓解便秘
|
总维生素d偏低会导致什么
|
惨不忍睹是什么意思
|
真情流露是什么意思
|
淋巴滤泡增生是什么意思严重吗
|
焦虑症是什么病
|
凤毛麟角什么意思
|
明天是什么生肖
|
决断是什么意思
|
花儿像什么比喻句
|
冲锋衣三合一是什么意思
|
彩超检查什么
|
洗葡萄用什么洗最干净
|
甲亢与甲减有什么区别
|
腹泻什么意思
|
湿气重什么原因
|
西红柿吃多了有什么坏处
|
白介素2是治疗什么病的
|
521是什么星座的
|
下雨为什么会打雷闪电
|
女性分泌物发黄是什么原因
|
相安无事什么意思
|
行气是什么意思
|
上山下金是什么字
|
红骨髓是什么意思
|
错构瘤是什么意思
|
了加一笔是什么字
|
女性腰疼是什么原因
|
一个火一个羽一个白念什么
|
标准差是什么
|
憋尿会造成什么后果
|
幼儿睡觉出汗多是什么原因
|
晕是什么意思
|
冶游史是什么意思
|
局气什么意思
|
水灵灵是什么意思
|
女攻是什么意思
|
孕期能吃什么
|
老鼠屎长什么样
|
日字五行属什么
|
雄脱是什么意思
|
2015年五行属什么
|
产奶速度慢是什么原因
|
牛肉炖什么好吃又营养
|
三线炎有什么症状
|
通情达理是什么意思
|
高密度脂蛋白偏高是什么原因
|
妇科病吃什么药
|
山珍海味是什么意思
|
舒化奶是什么意思
|
4级手术是什么意思
|
不能吃油腻的是什么病
|
屁眼疼是什么原因
|
跳绳有什么好处
|
窦性心律不齐是什么原因引起的
|
810是什么意思
|
小麦粉可以做什么
|
180是什么尺码
|
什么钙片补钙效果最好
|
包皮龟头炎吃什么药
|
法大大是什么
|
发乎情止乎礼什么意思
|
清蒸鱼一般用什么鱼
|
心火旺吃什么中药
|
刘庄为什么要灭了阴家
|
运动出汗多是什么原因
|
瑶字五行属什么
|
16岁能做什么工作
|
onemore是什么牌子
|
一什么树叶
|
阳暑吃什么药
|
水军是什么意思
|
露怯是什么意思
|
人生赢家什么意思
|
先自度其足的度是什么意思
|
什么叫走读生
|
什么是幸福
|
什么可以减肥
|
寒热错杂吃什么中成药
|
十一月七号是什么星座
|
缺血吃什么补血最快
|
公历是什么意思
|
睡不着觉是什么原因
|
魏丑夫和芈月什么关系
|
法国铁塔叫什么名字
|
不老实是什么意思
|
囧是什么意思
|
巴扎是什么意思
|
相什么并什么
|
挑刺是什么意思
|
为什么会梦到蛇
|
都有什么快递
|
1989年属蛇是什么命
|
日本为什么偷袭珍珠港
|
三点水加分念什么
|
梦到钱丢了预示着什么
|
把握时机是指什么生肖
|
促甲状腺激素高是什么原因
|
荨麻疹可以吃什么食物
|
十点半是什么时辰
|
杭州菜属于什么菜系
|
挑疳积挑出来的是什么
|
禾字加一笔是什么字
|
经常打屁是什么原因
|
韩束适合什么年龄段的人用
|
鸡打瞌睡吃什么药
|
四五月份是什么星座
|
矫正视力是指什么
|
小鸡吃什么
|
儿女双全是什么意思
|
银消病用什么药效果最好
|
口苦吃什么药最有效
|
萝卜喝醉了会变成什么
|
三百多分能上什么大学
|
甲亢是一种什么病
|
拆台是什么意思
|
S是什么牌子鞋
|
什么什么龙什么
|
风湿病是什么原因造成的
|
女生阴道长什么样
|
失信人是什么意思
|
紧急避孕药有什么危害
|
项羽为什么不杀项伯
|
耳石症是什么原因引起的
|
泌尿科属于什么科
|
家什是什么意思
|
维生素b6主治什么病
|
叶酸片有什么功效
|
五谷中的菽是指什么
|
珊瑚绒是什么面料
|
偷窥是什么意思
|
心肌供血不足用什么药
|
晚上睡觉喉咙干燥是什么原因
|
小儿鼻炎用什么药好
|
爬山是什么意思
|
女人喝黄酒有什么好处
|
白芍的功效与作用是什么
|
什么药清肺化痰好
|
肚子饿了为什么会叫
|
尿蛋白高是什么原因引起的
|
晨尿有泡沫是什么原因
|
舒张压偏低是什么原因
|
腋下臭是什么原因
|
秋葵有什么好处
|
双龙戏珠是什么生肖
|
耳朵痛什么原因
|
睁一只眼闭一只眼是什么意思
|
肾虚型脱发是什么样子
|
什么叫做缘分
|
百度
Chromium Blog
News and developments from the open source browser project
Intent to Explain: Demystifying the Blink Shipping Process
Tuesday, November 12, 2019
If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.
If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact
what
features get worked on, and how you can play a role in all of this!
Project goals
The
Chromium project
is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.
Blink
is the rendering engine used by Chromium. It is the part of the project that descends from
WebKit
(the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.
How does Blink improve the web platform?
By improving its
predictability
through testing and infrastructure, making sure developers have to spend less of their time tackling browser-specific issues and more of their time… well, developing.
By
removing user hostile features
, features that increase the platform’s complexity or make its implementations less secure.
By
adding platform capabilities
that enable web developers to innovate and create web experiences that meet and exceed their users’ expectations and needs.
If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.
Any improvement to the platform needs to take
backwards compatibility
and
cross-browser interoperability
into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and
tests
to guide future implementers.
The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability.
What features get worked on?
Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (
data
) come from Google, although about 20% of contributors are not Google-affiliated.
With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.
The
MDN survey
is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.
As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.
So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?
The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs.
Once we know which problem we want to tackle, we can start incubating it!
What does “incubating” mean?
Over the years, we found that the best way to design and prototype a new platform feature is through
incubation
- getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.
Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform.
Step 1 - Initial research
At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.
At the end of that phase, engineers are expected to publish an
explainer
that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the
WICG discourse
) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.
It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect.
Step 2 - Design & Prototype
Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.
Once we have an initial rough design, it might be a good idea to start building and committing code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.
That’s when engineers should send out an “
Intent to Prototype
” email to
blink-dev
(previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end.
That’s also a good point in time to make sure the feature will get a wider review, by filing for a
TAG review
.
Step 3 - Experiment & iterate
Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out.
Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike.
For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.
In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale.
Step 3.5 - Origin Trial
In those cases, a browser engineer can request an
Origin Trial
(by sending out an
Intent to Experiment
email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.
Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial.
Step 4 - ship it!
Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an
Intent to Ship
.
That’s a part of the process that’s
a bit more strict
.
In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.
What’s an “API owner”?
API owners
are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our
compatibility
and
interoperability
principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.
Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.
As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.
The feature needs to have a solid specification and a comprehensive cross-browser test suite in order to minimize interoperability risk.
Signals from other browser vendors as well as from wide review forums (such as the TAG) are taken into account, alongside signals from the web developer community and partners who are planning to use the feature.
If the feature went through an Origin Trial, a report outlining the results is also important to better understand the benefits.
Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.
Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums.
In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected.
Removing features
Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability.
Summary
The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform.
For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.
The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.
Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2025
Jul
Jun
May
Jan
2024
Dec
Aug
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
三无产品指的是什么
银925什么意思
老年脑是什么病
发泡实验阳性说明什么
握手言和是什么意思
炖排骨汤放什么调料
日什么月什么
吃什么可以软化肝脏
上嘴唇长痘痘是什么原因
病毒的遗传物质是什么
喝什么茶降血压最好最快
小寒节气的含义是什么
赵本山什么时候死的
梦见老鼠是什么预兆
口契是什么字
胃泌素17是什么检查
扁平疣用什么药膏管用
长期拉肚子是怎么回事什么原因造成
猴跟什么生肖配对最好
腰间盘膨出吃什么药效果好
罗姓男孩取什么名字好hcv8jop7ns3r.cn
六月二十日是什么日子hcv8jop2ns5r.cn
向内求什么意思hcv9jop6ns1r.cn
梦见大蜘蛛是什么预兆hcv9jop1ns0r.cn
2006年什么年hcv8jop0ns5r.cn
什么是公历年份hcv9jop7ns1r.cn
器质性是什么意思youbangsi.com
孵化是什么意思hcv8jop4ns3r.cn
KH是什么hcv9jop2ns3r.cn
香皂和肥皂有什么区别hcv7jop9ns3r.cn
十一月八号是什么星座hcv7jop9ns4r.cn
水瓜壳煲水有什么功效weuuu.com
减脂早餐吃什么hcv8jop0ns8r.cn
狗上皮过敏是什么意思520myf.com
脾湿热吃什么中成药hcv8jop9ns7r.cn
什么是功jasonfriends.com
宝宝满周岁送什么礼物hcv8jop5ns8r.cn
贞操带是什么hcv7jop7ns1r.cn
真如是什么意思qingzhougame.com
什么是细菌感染hcv9jop0ns4r.cn
百度
