#cssom

[saifosys]

CSS and JavaScript with syntax and examples

In this module, we'll explore the intersection of CSS and JavaScript, including CSSOM, CSS-in-JS, and JavaScript-controlled CSS animations. You'll learn about the syntax, examples, and best practices for using CSS and JavaScript together to create dynamic and interactive web applications. CSS and JavaScript - CSSOM (CSS Object Model): A JavaScript API for interacting with CSS. Syntax:…

[ayanahmed1]

插值是计算几个给定值之间的中间值的数学运算

这是因为，如果 DOM 节点较少，加载速度会更快，占用的内存也会更少，因此 CSSOM 的复杂性也会降低。此外，通过使用标识符和类，我们将拥有更高效的 CSS 选择器。字体优化字体是阻止在页面上绘制文本的关键资源。下载字体时，某些浏览器将显示带有系统字体的页面，而其他浏览器将显示不带文本的页面。

下载完成后，用户会看到字体如何变化或出现

这不会产生良好的印象。这是一个需要单独条目的主题，���总的来说，我会说您不应该加载不必要的字体，无论它们是同一字体的变体（粗体、斜体、粗体和斜体的不同粗细，…）还是我们不会在当前页面的语言中使用的字符集。仅对旧的 EOT 和 TTF 格式使用 Gzip 或 Brotli 压缩（不适用于 WOFF 或 WOFF2，因为它们已经被压缩），如果您想控制字体的加载方式，在本文中，您可以了解有关如何优化网站字体的更多信息。优化绘画避免 CSS 表达式CSS 表达式允许您使用 JavaScript 计算属性值。这除了违反了行为和风格的分离之外，对于浏览器来说效率非常低。所以最好用 JavaScript 来替换这些表达式。在 JavaScript 之前使用 CSS 创建动画使用 CSS 动画，您可以通过在一系列关键帧上的属性值之间创建插值来制作动画，就像使用 Flash 所做的那样。

对于那些不明白我的意思的人，。在这种情况下，它允许您沿着已建立的关键点计算CSS属性的值，以便浏览器可以执行动画。理想情况下，只应使用transform属性，它允许我们旋转、移动、放大或拉伸任何图层，以及opacity属性，以制作透明度。除了仅使用变换和不透明度属性之外，我建议使用具有固定或绝对位置的图层（以防止动画移动其余图层），因为这样可以防止浏览器启动回流和绘画，并且您只需要执行图层的合成。行相同的动画效率会低得多，因为它将与许多其他事情一起在 JavaScript 线程中运行，并且浏览器经过优化以流畅地运行 CSS 动画，优先考虑速度而不是平滑度。后者意味着，如果动画在一秒内向右移动图层 1000 像素，其中我们必须显示 60 帧，则该图层将在每帧中移动 16 像素。但如果浏览器只有时间绘制一半的帧，则每次重绘图层都会移动 32 像素。通过指定上面图层的图像比例来避免回流和重绘当您绘制页面时，某些图像可能会在最后加载，导致您必须在加载完它们后滚动它们下面的所有内容。为了避免这些跳跃， 每个图像必须包含在一个层中，该层所占据的高度与图像完成加载时所占据的高度相同。

实现此操作时必须考虑到图像将根据设

备而具有不同的尺寸，并按如下所示完成：首先，计算图像的高度与其宽度的比例：高度比=高/宽*100这给了我们一个百分比，我们将把它放在图像之前的图层的“padding-top”属性中，这样，无论宽度是否修改，该图层都将占据图像的高度。图像将具有相对于包含层的绝对位置，以便将其安装在确定高度的层的顶部。让我们看一个例子：<风格>#wrap-img-ej{ 职位：亲属； 最大宽度：将图层提升到GPU硬件，以便更快地绘制。但请避免过度使用这些GPU 提升规则，因为层需要内存并由浏览器进行管理。将改变的：转变；变换：translateZ(0)；这两个属性将具有相同的效果，但是“translateZ(0);”（我们用它来将 Z 轴移动到初始位置）适用于所有浏览器，而 will-change 是正确的方法实现它是因为它不会修改图层属性。将多个变换分组为旋转矩阵矢量对象的变换是通过将对象每个顶点的向量乘以一个矩阵来实现的，该矩阵给出了每个顶点的最终位置。该矩阵定义了我们要应用的变换类型（位置、缩放、旋转……）。

这就是当我们使用 Transform 属性对 CSS 层应用

二维或三维变换时，浏览器内部发生的情况。如果我们将生成我们要做的变换的所有矩阵相乘，无论是位置、缩放、旋转还是变形，我们都可以在一个步骤中一次性将它们全部应用到结果矩阵中，从而编写更少的代码和更多的代码。计算上的最佳方式，因为我们将使用这样的矩阵函数：如果是3D变换我们将使用matrix3D而不是matrix。此外，该函数允许我们进行其他方式无法完成的镜像效果转换：世界邮政组织CSS要快速计算变换矩阵（在头脑中完成并不容易），有必要使用一些 Sass 库、程序或函数来快速计算它，始终考虑到变换（如矩阵乘法）不会它是可交换的（平移和旋转与旋转和平移不同）。

2D 变换矩阵2D 变换矩阵简化难以表示的复

使用网格布局和 Flexbox 进行布局使 WhatsApp 数据库 用网格布局和/或 Flexbox比使用浮动层的布局（当然也比使用表格）更优化、更灵活。这里我们可以使用像 Bootstrap 这样的框架，它在版本 4 中已经使用了 Flexbox。使用这种新的布局方式，您可以直观地更改任何元素的位置，无论元素在 HTML 中的绘制顺序如何，比浮动层具有更大的自由度。这使我们能够在移动设备和桌面设备上拥有完全不同的分布，并且在 HTML 之上，出于 SEO 原因，我们首先要对其进行索引。避免极其复杂的选择器通常， 自动工具建议避免复杂的选择器，但我不建议过多关注这条规则，因为代码的可维护性总是比性能更重要。所以我的建议是只避免极其复杂的选择器，尽管你很少需要做这样低效的事情：div 为 *{}要知道选择器何时复杂或效率低下，我们必须考虑到选择器的更通用部分（元素）的效率低于更具体的部分（标识符）。

我们还必须了解选择器是从右到左解释的

因此将选择器的最通用部分放在右侧会使规则效率更低，因为这会导致浏览器必须检查 DOM 的更多部分才能知道是否它必须应用该规则。在上面的示例中， * 运算符选择页面上的所有元素，然后查看页面上所有元素的所有祖先是否都有链接，然后查看所有这些链接是否都有元素 p 祖先，等等on, a 除非在某个时刻找不到元素，在这种情况下选择器检查将停止。CSS3 伪元素和伪类也很慢（:first-child、:nth-child()、::firsts-line、::first-letter）。工具使用Chrome 和 Firefox 开发者工具来分析加载和绘制时间，调整测试以查看处理能力更有限和网络速度更慢的设备上会发生什么情况。在 Google Chrome 开发者工具中，通过单击“性能”选项卡右侧的���色齿轮即可显示最后这些选项。此外，这里还有“启用高级绘画仪器”选项，使我们可以在单击绘画事件时看到“Paint Profiler”选项卡。

这样我们就可以看到浏览器绘制页面所需执行的所有操作：Google Chrome 开发者工具 Paint Profile 浏览器在 Google Chrome 开发者工具和性能选项卡中，我们可以在“Paint Profiler”中检查绘画中发生的情况。 要研究 CSS 的速度以及 JavaScript 如何影响它，图形表示（渲染）选项卡中的选项非常有用，它可以实时向我们显示哪些矩形在页面上重新绘制以及速度。在绘制它时的 FPS 中。我们可以通过单击上一个屏幕截图中看到的同一屏幕，右上角的三个点，然后单击“显示控制台抽屉”并单击“渲染”选项卡来获得此选项：Chrome 开发工具渲染选项可实时查看移动滚动或动画的影响。Chrome 开发者工具的“渲染”选项卡中的选项可实时查看移动滚动或动画的影响。最终建议始终将可维护性置于性能之上非常重要，这就是为什么我建议始终以尽可能简洁的方式编写代码，使用某种组织方法，为类和标识符提供相关名称，并且如果您犯了不使用预处理器的错误，至少把制表符、换行符和空格全部放上，因为以后可以用工具最小化代码。什么是站点地图文件？站点地图是一个文件，其中包含网站上所有相关页面的列表以及有关这些页面的附加信息， 例如页面上的信息更改的频率、上次更新的时间或特定页面的重要性。

关于网站上的其余页面页面内容的修改

频率告诉 Google 应抓取网站上这些页面的频率。该文件的目的是帮助搜索引擎查找并索引您网站的页面。作为一般规则，爬虫会对它们找到的所有页面建立索引，除非它们包含某种类型的阻止指令。站点地图格式有多种，但最常用的是包含XML扩展名的格式。站点地图文件可以手动创建，也可以使用第三方工具生成，例如程序（例如XML Sitemap Generator）或每个内容管理器的特定插件（例如，有一些用于WordPress或Drupal）。创建站点地图文件不是强制性的，但建议这样做。所有网站管理员都应该为那些尚未考虑将其纳入的网站考虑其生成。重要的是，我们在生成站点地图期间要注意 Google 的规范和要求，以避免出现任何类型的错误或问题。如果创建后仍然出现错误或警告，那么我们必须仔细分析和解决它们，以便 Google 能够正确访问和处理该文件。蜘蛛如何找到我们网站上的页面？搜索引擎通过外部和内部链接发现新页面。例如，如果我们创建了一个新的登陆页面，并且它不包含入站链接，并且我们没有从网站内部链接它，则 Google 将无法找到它，因此无法将其编入索引。但是，也可能发生这样的情况：某个页面已从站点正确链接，但在层次结构中占据非常深的位置，因此爬虫程序很难到达该页面。通过站点地图文件，我们可以使搜索引擎更轻松地进行定位和发现工作。

将页面包含在此文件中并不能确保它们的爬行和索引

具有低质量内容（内容稀疏）的页面通常是那些尽管在站点地图中包含并发送它们但搜索引擎可能无法完成索引的 URL。这些通常是标签页面，列出包含 2 个或更少产品的 URL 等。所有未找到和抓取的页面都无法添加到 索引中，因此在用户执行相关搜索后无法返回结果。站点地图类型有不同类型的站点地图来描述多媒体内容和其他对于搜索引擎分析来说可能很复杂的内容。视频视频站点地图使我们能够向搜索引擎通报我们网站上的视频内容。

这是蜘蛛使用正常跟踪机制无法识别的信息。通过这种方式，我们可以提高网站在 Google 视频搜索中的可见度。站点地图视频条目可以指定视频的持续时间、类别和建议的年龄分级。视频站点地图语法但是，我们也可以在现有站点地图中指示视频内容，而无需为视频创建单独的站点地图。图像这种类型的站点地图将允许蜘蛛抓取我们网站上的图像并为其建立索引，从而提高我们对 Google 图片搜索的可见性。这是蜘蛛使用正常跟踪机制无法识别的信息。站点地图图像条目可以包括图像的主题、类型和许可。我们可以使用独立的站点地图来包含图像或将图像信息添加到现有站点地图中。

我们的联系方式

电报：https://t.me/dbtodata

Whatsapp：https://wa.me/8801918754550

[global-ai]

CSS Notes Professionals E-book

Download

Subjects covered include:

Getting started with CSS

Structure and Formatting of a CSS Rule

Comments

Selectors

Backgrounds

Centering

The Box Model

Margins

Padding

Border

Outlines

Overflow

Media Queries

Floats

Typography

Flexible Box Layout (Flexbox)

Cascading and Specificity

Colors

Opacity

Length Units

Pseudo-Elements

Positioning

Layout Control

Grid

Tables

Transitions

Animations

2D Transforms

3D Transforms

Filter Property

Cursor Styling

box-shadow

Shapes for Floats

List Styles

Counters

Functions

Custom Properties (Variables)

Single Element Shapes

Columns

Multiple columns

Inline-Block Layout

Inheritance

CSS Image Sprites

Clipping and Masking

Fragmentation

CSS Object Model (CSSOM)

Feature Queries

Stacking Context

Block Formatting Contexts

Vertical Centering

Object Fit and Placement

CSS design patterns

Browser Support & Prefixes

Normalizing Browser Styles

Internet Explorer Hacks

Performance

Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a document written in a markup language like HTML. CSS is a cornerstone technology of the World Wide Web, alongside HTML and JavaScript.

CSS is designed to enable the separation of presentation and content, including layout, colors, and fonts. This separation can improve content accessibility, provide more flexibility and control in the specification of presentation characteristics, enable multiple web pages to share formatting by specifying the relevant CSS in a separate .css file, and reduce complexity and repetition in the structural content.

Separation of formatting and content also makes it feasible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. CSS also has rules for alternate formatting if the content is accessed on a mobile device.

The name cascading comes from the specified priority scheme to determine which style rule applies if more than one rule matches a particular element. This cascading priority scheme is predictable.

The CSS specifications are maintained by the World Wide Web Consortium (W3C). Internet media type (MIME type) text/css is registered for use with CSS by RFC 2318 (March 1998). The W3C operates a free CSS validation service for CSS documents.

In addition to HTML, other markup languages support the use of CSS including XHTML, plain XML, SVG, and XUL.

CSS has a simple syntax and uses a number of English keywords to specify the names of various style properties.

A style sheet consists of a list of rules. Each rule or rule-set consists of one or more selectors, and a declaration block.

Read more

[gotasenseivebeenbetrayed]

So I was just relistening to CSSOM and had looked into Harry and "drugs" because I know that line is specifically why everyone is like "no no it HAS to be Matty" and I want to add something.

Harry has done a few interviews where he mentions after leaving 1D he started doing drugs, the one he's insistant on is how when he writes now he tends to do pills or shrooms to help the process which brings me back to this line.

"You turned me into an idea of sorts You needed me but you needed drugs more And I couldn't watch it happen"

"turned me into an idea of sorts" gives me the vibe she's referring to how she was his muse and then he started needing drugs to write instead "you needed me but you need drugs more".

Obviously I could be wrong, hell we all could and all this time Matty truly has been her *muse* but, I'm sorry I just don't believe it lol. I'll also reiterate that I still do believe it's possible the drug line was thrown in just to paint Matty as the muse. Same with how she talked about drugs/pills/heroin in a few lyrics through out TTPD which everyone knows Matty was an addict. To which I want to also remind you: him and his band mates have said he's been clean for years now and as a fan of the 1975 and former Matty fan I (and other fans) noticed a huge difference from when he was on drugs vs now. I do not think he's lying. So it doesn't really make sense for her to be calling him out as an addict still if the songs are about him. I think it's her "bait and switch" and she's done this PLENTY with muses. Red being the "Jake" album where it actually turns out it probably isn't. Reputation being "Joe" when most of it was written before she met Joe. As she's gotten older she's definitely mixed muses or used a "cover up" for the real muse. Would not surprise me if that's what she did here.

Decade/10 Years

I'm not sure if this has been brought up by anyone else but, I was just thinking. So her mentioning a decade in Chloe, Sam, Sophia or Marcus - ("as the decade would play us for fools") but, essentially that's one of the points that Maylors are using to confirm Matty as the muse to which I have to say this.

× Met Matty in Oct/Nov of 2014

× 10 years later would be Oct/Nov of 2024 (which we are not even at yet)

× Taylor dated Matty for a brief time mid last year, 2023, 10 years would be 2013 and they had not met

What are the odds that Taylor, who is very precise in her lyrics and timings, who *apparently* wrote "Fortnight" aka two weeks about her relationship with Matty, would then negate all of that and say "I plan to release this album a year later which will technically then be a decade since I met Matty minus 6 months so I'll go ahead and use the decade speak even though it's not accurate."? vs her speaking about someone else, aka Harry.

× Started writing TTPD after Midnights. That would indicate she started writing it late 2021 into 2022. 10 years would be 2012 aka when her and Harry started dating.

× Some of the songs would then have been written also last year in 2023. 10 years would be 2013 aka both when they officially broke up, when they tried again and when 1989 was worked on.

So again, what are the chances she'd write about a "decade" in regards to Matty in a future pretense or by rounding up the time frame vs actually talking about a "decade" in regards to someone she ACTUALLY dated/knew for a decade when she was writing said song?

This would be easier to piece together if we had the actual datea of when songs were written *fingers crossed* we get that some day cause I feel that would help erase Matty as the muse for TTPD lol.

[bellisajean]

HTML 파싱

HTML 파싱이란 HTML 문서를 분석해서 그 구조를 이해하고, 각 요소(태그, 텍스트, 속성 등)를 프로그램에서 사용할 수 있는 형태로 변환하는 과정을 말합니다. 웹 브라우저나 웹 크롤러, 다양한 프로그래밍 언어에서 HTML을 처리할 때 필요한 과정입니다.

HTML 파싱 과정은 대체로 다음 단계를 포함합니다:

토큰화(Tokenization):

HTML 문서는 문자의 연속입니다. 파서(parser)는 이 문자들을 의미 있는 단위, 즉 토큰(token)으로 분리합니다. 예를 들어, '<', 'a', 'href="..."' 등이 토큰이 될 수 있습니다.

구문 분석(Syntax Analysis):

토큰들을 구문적으로 해석하여 HTML의 구조를 이해합니다. 이 단계에서는 토큰들을 DOM(Document Object Model) 트리라는 구조로 조립합니다. DOM 트리는 HTML 문서의 계층적 구조를 반영합니다.

DOM 트리 생성:

각 HTML 태그는 DOM 트리에서 노드(node)가 됩니다. 예를 들어, <html>, <body>, <div>, <p> 같은 태그가 모두 트리의 노드가 됩니다.

텍스트 내용도 텍스트 노드로 트리에 포함됩니다.

CSSOM 생성 (선택적):

HTML 파싱과 병행하여, CSS 파싱이 진행되어 CSSOM(CSS Object Model) 트리도 생성됩니다. 이 트리는 HTML 요소에 적용될 스타일 정보를 포함합니다.

렌더 트리 생성 (브라우저에서):

DOM 트리와 CSSOM 트리를 결합하여 렌더 트리(Render Tree)를 생성합니다. 렌더 트리는 실제로 화면에 그려질 요소들만 포함합니다.

레이아웃(Layout):

각 노드가 화면의 어디에 위치할지 계산합니다.

페인팅(Painting):

레이아웃 계산 결과에 따라 화면에 요소들을 그립니다.

HTML 파싱은 매우 복잡하고 세밀한 과정입니다. 웹 브라우저는 이 과정을 매우 빠르고 효율적으로 수행하여, 우리가 웹 페이지를 볼 때 눈에 보이는 내용이 화면에 나타나게 합니다. 프로그래밍에서는 HTML 파싱을 통해 웹 페이지의 데이터를 추출하거나, 웹 페이지를 분석하고 조작하는 다양한 작업을 할 수 있습니다.

[haggen]

If you use CSS in your daily work, your primary goal is probably focused around making things ‘look right’. How this is achieved is often far less important than the end result. This means we care less about how CSS works than the correct syntax and visual results.

[transienturl]

Aw, I forgot to write it down, but I did learn something really fascinating while looking into CSS-in-JS libraries: there's a method to create style elements in Javascript that results in, if you look in the developer tools DOM inspector, what appears to be an empty style tag. I think these are related:

https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet

https://developer.chrome.com/blog/css-in-js/

https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model

...but, truthfully I'm pretty unclear on it.

The biggest thing I'm not currently clear on is the relationship between the "HTML-looking" representation of styles, the "Javascript-object-looking" sort, and the actual native storage of this data (presumably in the DOM? But I'm not clear on this either?)

Like, with the web content itself, the <div data-id="eggplant">hi!</div> HTML text gets parsed into DOM elements, which is the real internal representation, and Javascript has ways to query and manipulate the DOM elements like Javascript objects (thatDiv.dataset.id === 'eggplant'). And when you inspect the page with dev tools, it generates <html> text that represents the current state of the DOM so you can see what's going on. Took me a while to understand that.

So the same could be said about the styles, rather than the content, I assume? That is, traditionally you write styles in a css text form div { color: red; }, but internally they're stored as [CSSOM elements?],and Javascript has ways to query and manipulate the CSSOM elements like Javascript objects ([example goes here]), when you inspect the page with dev tools... well, apparently in some cases you get the appearance of an empty style tag, but you can read the sheet data with Javascript!

As mentioned in that Chrome link, elements styled with this sheet will have their styles parsed to text when you inspect them with dev tools, but if you click the "where is this style defined" button next to them, you end up at (again, what appears to be) a blank style tag.

I have three immediate thoughts on this:

a) Neat, a performance gain! I like those.

b) Wait, what other super important data can be attached to a DOM element that I can't see in the devtools inspector?

c) Wait, is there other super important data that can be attached to a DOM element that I can't see using Javascript either? Where's the MDN link for "here is every type of DOM element and every type of attribute it can have?"

[cannedsoupsucks]

I love Ellaria!

Aphelion - 7

Pairing: Oberyn Martell x Female Reader, Oberyn Martell x Ellaria Sand

*Please be sure to consider all chapter warnings before reading! Warnings will be updated for each chapter in individual posts as well as on the Masterlist.

Warnings: blood, serious injury (Reader and Oberyn), graphic description of injury, vampires and other such supernatural things 

Word Count: 10,951

Summary: Ellaria finally arrives - but is she in time to save Oberyn? And if she’s not too late, will he survive what needs to be done in order to heal him? And what about you - who are you, and what do you really mean to Oberyn? 

A/N: This story had been a TON of fun for @something-tofightfor​ & I to write, and seeing your response and reactions to it as it unfolds has only made that more true. We just want to say thank you to anyone who has given this a read, left a comment or reblog or reached out to either of us in any way. This part might start out a little… grim? But it’s definitely a turning point in the story, and we are both excited about what happens here AND what comes next. Enjoy!! 

Also, if you have questions about details or plot points or the way that Westerosi history/world fits into the “real” world- please ask! We don’t want to confuse anyone.

Catch up with the Aphelion masterlist here

(banner by @valkblue​ )

Nothing could have prepared her for what she saw when she entered the bedroom. 

She’d been able to smell him - the stench of decaying flesh, of rot, sickness that permeated the entire apartment - from the moment she’d stepped through the door. But for Ellaria Sand, the sight of Oberyn in bed, his usually tanned skin nearly the same color as the sheets and his body slick with perspiration was enough to stop her in her tracks. My Prince. 

Both hands shooting up to her mouth to cover it as her lips parted in shock, she gave herself only a single second to let the scene sink in and then she was moving forward again, feet carrying her soundlessly across the small bedroom and to his side. “I am here, Oberyn.” Without touching him, she leaned close, mouth directly next to his ear. “I am here and I will help you.” 

He didn’t respond to the sound of her voice - something that had never been the case in the thousands of years she’d known him. At that, she couldn’t help touching him, her hands reaching out to cradle his face and turn it toward her, willing him to open his eyes. You must. Repeating his name, she waited for any sign of recognition, her fingers gently stroking over his smooth skin, the chill of it radiating through her palms.

Keep reading

[kedama-mz]

いつのまにかcssで出来る

[kimromi4]

2023-01-14(Sat)

今日は年が明けてからちょうど2週間。年明けから始めたものがまだ続いているのでとりあえずよかった。

インプット1時間

運動30分

日記を書く（途中から見えるところに書くようにした）

といってもまだ2週間なので誇れるものはないが、次は1ヶ月を目指してちゃきちゃきやっていこうと思う。

https://developer.mozilla.org/ja/docs/Web/API/Document_Object_Model

https://developer.mozilla.org/ja/docs/Web/API/Document_Object_Model/Introduction

恥ずかしながら、今さらこのあたりから DOM について学んだけど、なんで今まで学ばなかったんだという気持ちが強い。

ブラウザが HTML を受け取って DOM tree にするとか、document っていう JS の API とか、Virtual DOM の話とか、CSS のカスケード（こっちは CSSOM だけど）のイメージとかが一気になんか点と点が線で繋がった感覚があって感動がある。

JS で Element に対して何か操作すること DOM ���操作するって言ってた（言葉としては微妙に合ってしまっているけど Element と DOM の意味合いをわからず言っていた）けど、誤用だったなと反省。。

[webstick0012]

divi en avada

divi en avada zijn twee populaire gratis WordPress-thema's die ideaal zijn voor bloggers en online bedrijfsmensen. Zowel Divi als Avada bieden een schone, overzichtelijke en zeer functionele interface voor website-eigenaren en bloggers. DIFI en AVADA zijn geweldige oplossingen voor zowel beginners en professionals, en bieden alles van een elegant standaard thema aan de meest geavanceerde grafische afbeeldingen die vandaag in de industrie beschikbaar zijn. Dit artikel biedt u een overzicht van DIVI en AVADA en u kunt u helpen een geïnformeerde beslissing te nemen over welk thema geschikt is voor u.

DIVI is een krachtig standaard thema door elegante thema's met een sterke gebruikersbasis van meer dan 700.000 wereldwijde ondernemers en ontwerpers. Avada, anderzijds, is een bekroond WordPress-thema met meer dan 620.000 downloads. DIVI en AVADA zijn bedoeld om een schone, overzichtelijke en zeer functionele interface te bieden voor websites en bloggers. Hier is een nadere blik op de functies die elk thema biedt:

Deze thema-oplossingen met twee DIFI en Avada behoren tot de meest populaire en veelgebruikte WordPress-thema's vandaag. Hoewel beide een krachtig standaard thema aanbieden, heeft DIFI de rand als het gaat om maatwerk. U kunt uw eigen thema helemaal opnieuw maken, personaliseren het met uw eigen kleurenschema en -logo, en vervolgens gebruiken in combinatie met de rest van de DIVI- en Avada-thema's. Aan de andere kant kunt u ook het standaardthema voor DIFI gebruiken en hetzelfde effect hebben als het gebruik van een ander kleurenthema. Dus wat is beter tussen Divi en Avada?

In termen van sjabloonbibliotheek en functieset zijn zowel Divi als Avada vergelijkbaar genoeg. Beide zijn veelkleurig en hebben een uitgebreide catalogus van sjablonen voor headers, kolommen, voetteksten, zijkanten, banners en plug-ins. Een groot verschil tussen de twee thema's ligt echter in hun standaard sjabloonbibliotheek. DIFI maakt gebruik van een kleinere sjabloonbibliotheek terwijl Avada een grotere gebruikt.

Voor sommige mensen is het grootste verschil tussen Divi en Avada de hoeveelheid aanpassing die ze bieden. Beide zijn multicolor en hebben uitgebreide catalogi van sjablonen. Er zijn echter enkele gevallen waarin slechts één sjabloon in een blog of een site wordt gebruikt. In dit geval kunt u kiezen voor slechts één sjabloonresource en de functionaliteit krijgen die u nodig hebt voor die site. In het geval van DIFI zou dit betekenen dat u geen afzonderlijke multifunctionele thema's hoeft te hebben voor elke site en het zou een installatie met één locatie zijn.

De lay-outmotor van DIFI en Avada is themafusie. Dit is een zeer krachtige lay-outmotor die verschillende interessante gereedschappen biedt. Het heeft ook een volledige steun voor CSS-preprocessors zoals CSSOM en minder. In feite, als het gaat om het aanpassen van DIFI- en Avada-sites, is het enige dat u hoeft te doen een sjabloon uit het gedeelte Sjablonen & lay-outs en vervolgens een pictogram kiezen en uw pagina aanpassen. Natuurlijk, als u niet de tijd hebt om uw pagina's zelf aan te passen, kunt u altijd gebruikmaken van de professioneel ontworpen lay-outs die worden verstrekt door ThemAfusion.

Een belangrijker kenmerk van Divi en Avada is dat ze allebei een premium paginabuilderservice bieden. Met deze service krijg je toegang tot professionele ontwerpers die lichaamsjablonen, nieuwsbriefmeldingen kunnen maken en vanaf nul contact met ons opnemen in Divi en Avada. U hoeft niet langer een webontwerper in te huren om aangepaste pagina's voor uw bedrijf te maken;U kunt ze allemaal in DIFI en AVADA maken en plaatst u eenvoudig uw websites-logo en afbeeldingen.

Hoewel het waar is, bieden DIVI en Avada voorgebouwde sjablonen en thema's, ze worden nog steeds beschouwd als beter dan andere gratis online pagina-bouwers. Mensen geven inderdaad de voorkeur aan het gebruik van DIVI en AVADA voor het bouwen van gepersonaliseerde webpagina's omdat het de optie geeft om veel verschillende skins in slechts één toepassing te gebruiken. Bovendien, aangezien beide gratis webpagina-bouwers thema's bieden voor zowel professioneel als persoonlijk gebruik, kunt u de juiste vinden om te gebruiken, ongeacht uw specifieke bedrijfsbehoeften. Als u betere websites voor uw bedrijf wilt bouwen, zou ik voorstellen dat u zowel Divi als Avada beschouwt.

[cannedsoupsucks]

So much tension and angst and I loved every minute of it!

Aphelion - 6

Pairing: Oberyn Martell x Female Reader, Oberyn Martell x Ellaria Sand

Word Count: 9,500

*Please be sure to consider all chapter warnings before reading! Warnings will be updated for each chapter in individual posts as well as on the Masterlist.)

Rating: M. This one is serious. You’ve been warned. 

Warnings: blood, serious injury (Reader and Oberyn), discussion of/acceptance of death, Oberyn doesn’t explicitly ask for permission every time he drinks, talk of the past, vampires and other such supernatural things

Summary: Reaching out to Ellaria doesn’t mean that she’s going to get to you right away … so where does this leave you and Oberyn in the between-time? 

With both of you growing weaker by the minute, all you can do is find ways to pass the time, and hope for a little extra ‘help’ from your surroundings… and when Oberyn asks for one last favor, there’s no way you can deny him.

A/N: This has been a long time coming, but it was really important for us to get this chapter right, and we wanted to take our time. @the-blind-assassin-12 really hope that you ‘enjoy’ (as much as possible) this chapter - we can promise that from here on out, things won’t be straight up angst or hopelessness. You’ll see. Thank you for being patient with us - if you’d like to be tagged, please feel free to ask either one of us! 

Also, if you have questions about details or plot points or the way that Westerosi history/world fits into the “real” world- please ask! We don’t want to confuse anyone.

Catch up with the Aphelion masterlist here

(header made by @valkblue)

You were hovering in the stillness between life and sleep when you heard him speak your name. 

Oberyn’s voice met your ear like a magnet, pulling you up and fully back into the waking world. Opening your eyes and blinking a few times to adjust to the light in the room, you took a deep breath inthrough your nose. It’s morning. His arm was still around your waist, keeping you close to his body, and for half a second you let yourself revel in that thought. It’s morning and we made it. 

You didn’t notice the threadbare tone in his voice as he tried to wake you. Or the heaviness of the limb he had draped over you, no longer holding tightly but laying like dead weight over your ribs. Not at first. 

Keep reading

[manualdabencao]

Você pode ser um canal para o fluir do Espírito? https://www.instagram.com/p/CSsOM-WrWRb/?utm_medium=tumblr

[cannedsoupsucks]

This is such a unique AU! I've never seen a Dr. Jekyll and Mr. Hyde AU and you picked two perfect charters to be in it. I would love to read more if you feel inspired to write more. Also your poem is really lovely ❤

& then we were infinite, part ii

oberyn martell x f!reader, ezra (prospect) 

18+ only, rating: mature, endless love & a little magic with a good doctor, & an enigmatic prince, a dr. jekyll & mr. hyde au ✨

Nudging over the sting of an unapologetic mark he's left behind

with the gliding arch of his nose,

and the pleasurable scratching of his chin,

somehow his more darkened senses lie in tune with

how overwhelmingly breathless

you truly had become.

It becomes a feverish slide, this feeling of both hands grazing themselves in curious circles there upon your face; you'd only ever been used to the one with Ezra, a stillness of touch felt from within, in subtle, different ways. 

Yet, under the spell of this newfound luxury, you wondered if he too had felt this thrumming sensation; if he felt your tenderness beneath it, sensing something missing.

"Does your mind always tend to wander off when a man is touching you, little bird?"

No matter how forward the sentiment, Oberyn's eyes seem entirely sincere; the back of his smooth fingers trailing over your skin in patient admiration, watching steadily as your eyes fall further closed, imagining it to be him.

"Prince Martell, I believe that is no business of yours…"

There's a featherlight change in the air between you, a tension that lifts despite all it was you had just said to him; his darted over whisper, fanning its heat over your lips.

"Only Oberyn when I have you, please."

Breathing you in, he cradles you softly by way of your neck, moving past the pretty corners of your mouth with a sharpened smile, hovering, as if so completely sure of himself; nothing distant there about him, when he makes sure to press a kiss to your skin so deeply there…

Nudging over the sting of an unapologetic mark he's left behind with the gliding arch of his nose, and the pleasurable scratching of his chin, somehow his more darkened senses lie in tune with how overwhelmingly breathless you truly had become.

oh.

"Oberyn…"

Your heartfelt loss for words lingers into something soft, moving with the more than capable palms of his hands; the feeling itself, intensely heightened, and tenderly surrounding you both.

"Forgive me…"

But only for a moment does he find it better to step reluctantly away, instead encasing your hand safely there inside his, where your fingers have been left to aimlessly intertwine; rather than the swell of his lips savoring in the pure essence of your skin, just how he would like to; forgetting himself that it was Ezra's heart you had belonged with, after all.

…

For a while you hadn't been entirely sure as to how you felt about this sudden change; wholeheartedly intrigued by Oberyn, & getting lost in his all consuming distraction; drifting into worrying for your Doctor, and where he could have possibly disappeared to.

So for now, all you can think of doing, is to go about the rest of your day, to have a quiet picnic in the garden of your home just as you had planned before; averting your eyes to all the softened staring of your Prince as he wanders close, leisurely at your side.

Yet, when he brings your fingertips delicately to his lips to kiss all of them there, you had sworn to try your absolute best to hide the fall of sighing, escaping from the very warmth of your chest. 

"Have I made you nervous? You need not fear me…"

Looking to him then, he regards all of you amidst the fading sunlight; his touch, rendering you speechless in your heartfelt shades of stillness, as you stand together all alone; thinking of Ezra and how often his deep brown eyes tend to do the same; the trees, dancing in the wind, as their fanning of green, latches onto the fleeting sounds in the air.

"It is because I do not fear you at all, that troubles me."

"Because I am familiar."

Your quiet nod of 'yes' indulges him completely, no matter how far off, or wistful your thoughts may seem; already it is the beauty of your simple gesture that sends his curious mind, into a loving sort of spiral. 

"Then let us stay that way, do things as you would if I had been your Ezra."

…

Where daylight soon had traced a path kindly toward the shade, you sit with Oberyn relaxed amidst a woven blanket you had brought with you outside; watching from behind a book of poems as he treats himself to such lovely delights you've given him; black cherries and dark chocolate, brought slowly into a very practiced mouth as he lounges with his legs crossed over…

Smiling between his glossed over fingertips, his graceful eyes look up when you've noticed him.

"Read to me, indulge me in your sweet sound…at least, in this way, for now." 

He exudes a patient sort of confidence, and it seems that he knows this; a feeling that comes in the form of a comforting string of words, most often elegantly laced together by another, you had been so intimately fond of.

You can not help but wonder, if parts of him were capable of coming through; if he knew how much you needed him, afraid that so swiftly you'd already been far gone during this wondrous short passage of time; finding yourself falling, faster than ever.

"Amidst the breeze, 

there are the clouds 

that gently follow; 

a thin veil of grey 

that hints solemnly 

at a fine Spring rain.

Though, no matter how weary,

there is a kind Morning Dove  

who flies endlessly toward it;

a brush of sadness

held within its eyes…"

There becomes a moment when your whisper soon trails off, fading into the last remains of light, only for Oberyn to catch up with you there; leaning over to hold your hand against his face, when he speaks to you once more.

"... because the beauty of the Sun, 

has all but gone away."

"You know this one by heart?"

"Somehow the words have been instilled in me, however bereft of thought, they've appeared to me in my mind."

Sliding away from your lap, your book of poems falls into a gentle close, where all of your well loved pages begin to unravel against the breeze; suddenly, it is your wayward sense of missing that wills yourself into reading from it no more.

"How?"

"Perhaps it is a memory that remains of the Good Doctor. His love for you runs fervently, even more so than my own."

"Your own?"

"Yes, sweet girl, I am a Prince, but not one devoid of great emotion."

With a subtle tilt to his chin, the tip of his nose grazes lightly there at your wrist, stealing your breath away with a kiss pressed deeply to your skin; the sole essence of his very being, commanding all your vision to his opened, sun lit robe, where your eyes have lingered on his chest beneath it.

"Oberyn, I do not understand…"

Winding, winding, winding, hurriedly a spark of things invites you only nearer; the strength of his arms, holding you tightly to him, as if by way of the wind, telling him that his time with you had soon been up.

And left so incredibly uncertain, selfishly you wished for a single moment to spend with him, just a while longer.

"Will sadness dampen your eyes as it had to your Morning Dove, when I too, have slipped away?"

The smooth padding of your thumbs drift idly past his cheek, before trailing your softened touch lower along the plush edges of his lips; committing the pursed bow of their seriousness to the safe haven of your memory, until you've almost leaned in to savor them with a kiss of your own.

nervousness, 

and distant

hovering.

"I admit, my thoughts haven't carried me that far."

"Then, I will leave you with something only I am capable of..."

His not so subtle way of being collides with you so hard; a kiss parted deeply there from a longing realm of dreams, knowing all the dragging places leading toward, the affectionate whisper of your mouth.

Latching on slow, your lips begin to slot between his, fitting perfectly together in your tinted loving rhythm, so lightly tentative and soft; that is until he's captured you by the slanted grasping of his hand cradling the back of your neck, pulling you closer, at the pliant small of your back with the other.

The velvet groan he's leant to your caged in spaces, rises impatiently from his chest; circling with his tongue in your deftly made wrap around, fueling all else to cease in its existence, surrendering your eyes to a soothing close…

That when you think of pulling apart to ground yourself, remembering how it feels just to catch your breath, your Prince born of a radiant, saccharine gold becomes so silently lost; your heart, taking kindly to the low and tender drawl of a voice there, you've come to know so well.

"My most breathtaking treasure, how relieved I am to feel you like this, to be with you once more. The shadows of the mind have enveloped my heart long enough…"

"Ezra…? Is it really…? Are you…?"

And he shows you this time, wordlessly, without telling, something he's intuitively picked up on from the more regal vision of himself; kissing you between stray gasps of heartfelt air, and most tired eyes, whispering to your pebbled skin that he was in fact there, relieved, and pressing, his forehead gently onto yours.

… 💛

a/n -- thanks so much for reading 🌼 still don't know where this story is going, so for now I will leave it here. 🥰

the poem about the morning dove flying toward the spring rain is my own, inspired by nature & silver linings.

I do not claim any fan related terms of endearment used with Oberyn or Ezra, & of course all of this is completely open to your own imagination. 🙏💛

I would love to hear what you think, & if this is in any way similar to something that's already been written, I will kindly take it down. xo 💫

[siliconwebx]

The Widening Responsibility for Front-End Developers

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”

The moment I fell in love with front-end development was when I discovered the style.css file in WordPress themes. That’s where all the magic was (is!) to me. I could (can!) change a handful of lines in there and totally change the look and feel of a website. It’s an incredible game to play.

Back when I was cowboy-coding over FTP. Although I definitely wasn’t using CSS grid!

By fiddling with HTML and CSS, I can change the way you feel about a bit of writing. I can make you feel more comfortable about buying tickets to an event. I can increase the chances you share something with your friends.

That was well before anybody paid me money to be a front-end developer, but even then I felt the intoxicating mix of stimuli that the job offers. Front-end development is this expressive art form, but often constrained by things like the need to directly communicate messaging and accomplish business goals.

Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.

I love it.

Looking back at the courses I chose from middle school through college, I bounced back and forth between computer-focused classes and art-focused classes, so I suppose it’s no surprise I found a way to do both as a career.

The term “Front-End Developer” is fairly well-defined and understood. For one, it’s a job title. I’ll bet some of you literally have business cards that say it on there, or some variation like: “Front-End Designer,” “UX Developer,” or “UI Engineer.” The debate around what those mean isn’t particularly interesting to me. I find that the roles are so varied from job-to-job and company-to-company that job titles will never be enough to describe things. Getting this job is more about demonstrating you know what you’re doing more than anything else¹.

Chris Coyier Front-End Developer

The title variations are just nuance. The bigger picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:

front-end = browsers

back-end = servers

Even as the job has changed over the decades, that distinction still largely holds.

As “browser people,” there are certain truths that come along for the ride. One is that there is a whole landscape of different browsers and, despite the best efforts of standards bodies, they still behave somewhat differently. Just today, as I write, I dealt with a bug where a date string I had from an API was in a format such that Firefox threw an error when I tried to use the .toISOString() JavaScript API on it, but was fine in Chrome. That’s just life as a front-end developer. That’s the job.

Even across that landscape of browsers, just on desktop computers, there is variance in how users use that browser. How big do they have the window open? Do they have dark mode activated on their operating system? How’s the color gamut on that monitor? What is the pixel density? How’s the bandwidth situation? Do they use a keyboard and mouse? One or the other? Neither? All those same questions apply to mobile devices too, where there is an equally if not more complicated browser landscape. And just wait until you take a hard look at HTML emails.

That’s a lot of unknowns, and the answers to developing for that unknown landscape is firmly in the hands of front-end developers.

Into the unknoooooowwwn. – Elsa

The most important aspect of the job? The people that use these browsers. That’s why we’re building things at all. These are the people I’m trying to impress with my mad CSS skills. These are the people I’m trying to get to buy my widget. Who all my business charts hinge upon. Who’s reaction can sway my emotions like yarn in the breeze. These users, who we put on a pedestal for good reason, have a much wider landscape than the browsers do. They speak different languages. They want different things. They are trying to solve different problems. They have different physical abilities. They have different levels of urgency. Again, helping them is firmly in the hands of front-end developers. There is very little in between the characters we type into our text editors and the users for whom we wish to serve.

Being a front-end developer puts us on the front lines between the thing we’re building and the people we’re building it for, and that’s a place some of us really enjoy being.

That’s some weighty stuff, isn’t it? I haven’t even mentioned React yet.

The “we care about the users” thing might feel a little precious. I’d think in a high functioning company, everyone would care about the users, from the CEO on down. It’s different, though. When we code a <button>, we’re quite literally putting a button into a browser window that users directly interact with. When we adjust a color, we’re adjusting exactly what our sighted users see when they see our work.

That’s not far off from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience. While a back-end developer might care deeply about the users of a site, they are, as Monica Dinculescu once told me in a conversation about this, “outsourcing that responsibility.”

We established that front-end developers are browser people. The job is making things work well in browsers. So we need to understand the languages browsers speak, namely: HTML, CSS, and JavaScript². And that’s not just me being some old school fundamentalist; it’s through a few decades of everyday front-end development work that knowing those base languages is vital to us doing a good job. Even when we don’t work directly with them (HTML might come from a template in another language, CSS might be produced from a preprocessor, JavaScript might be mostly written in the parlance of a framework), what goes the browser is ultimately HTML, CSS, and JavaScript, so that’s where debugging largely takes place and the ability of the browser is put to work.

CSS will always be my favorite and HTML feels like it needs the most love — but JavaScript is the one we really need to examine The last decade has seen JavaScript blossom from a language used for a handful of interactive effects to the predominant language used across the entire stack of web design and development. It’s possible to work on websites and writing nothing but JavaScript. A real sea change.

JavaScript is all-powerful in the browser. In a sense, it supersedes HTML and CSS, as there is nothing either of those languages can do that JavaScript cannot. HTML is parsed by the browser and turned into the DOM, which JavaScript can also entirely create and manipulate. CSS has its own model, the CSSOM, that applies styles to elements in the DOM, which JavaScript can also create and manipulate.

This isn’t quite fair though. HTML is the very first file that browsers parse before they do the rest of the work needed to build the site. That firstness is unique to HTML and a vital part of making websites fast.

In fact, if the HTML was the only file to come across the network, that should be enough to deliver the basic information and functionality of a site.

That philosophy is called Progressive Enhancement. I’m a fan, myself, but I don’t always adhere to it perfectly. For example, a <form> can be entirely functional in HTML, when it’s action attribute points to a URL where the form can be processed. Progressive Enhancement would have us build it that way. Then, when JavaScript executes, it takes over the submission and has the form submit via Ajax instead, which might be a nicer experience as the page won’t have to refresh. I like that. Taken further, any <button> outside a form is entirely useless without JavaScript, so in the spirit of Progressive Enhancement, I should wait until JavaScript executes to even put that button on the page at all (or at least reveal it). That’s the kind of thing where even those of us with the best intentions might not always toe the line perfectly. Just put the button in, Sam. Nobody is gonna die.

JavaScript’s all-powerfulness makes it an appealing target for those of us doing work on the web — particularly as JavaScript as a language has evolved to become even more powerful and ergonomic, and the frameworks that are built in JavaScript become even more-so. Back in 2015, it was already so clear that JavaScript was experiencing incredible growth in usage, Matt Mullenweg, the founding developer of WordPress, gave the developer world homework: “Learn JavaScript Deeply”³. He couldn’t have been more right. Half a decade later, JavaScript has done a good job of taking over front-end development. Particularly if you look at front-end development jobs.

While the web almanac might show us that only 5% of the top-zillion sites use React compared to 85% including jQuery, those numbers are nearly flipped when looking around at front-end development job requirements.

I’m sure there are fancy economic reasons for all that, but jobs are as important and personal as it gets for people, so it very much matters.

So we’re browser people in a sea of JavaScript building things for people. If we take a look at the job at a practical day-to-day tasks level, it’s a bit like this:

Translate designs into code

Think in terms of responsive design, allowing us to design and build across the landscape of devices

Build systemically. Construct components and patterns, not one-offs.

Apply semantics to content

Consider accessibility

Worry about the performance of the site. Optimize everything. Reduce, reuse, recycle.

Just that first bullet point feels like a college degree to me. Taken together, all of those points certainly do.

This whole list is a bit abstract though, so let’s apply it to something we can look at. What if this website was our current project?

Our brains and fingers go wild!

Let’s build the layout with CSS grid. 

What fonts are those? Do we need to load them in their entirety or can we subset them? What happens as they load in? This layout feels like it will really suffer from font-shifting jank. 

There are some repeated patterns here. We should probably make a card design pattern. Every website needs a good card pattern. 

That’s a gorgeous color scheme. Are the colors mathematically related? Should we make variables to represent them individually or can we just alter a single hue as needed? Are we going to use custom properties in our CSS? Colors are just colors though, we might not need the cascading power of them just for this. Should we just use Sass variables? Are we going to use a CSS preprocessor at all?

The source order is tricky here. We need to order things so that they make sense for a screen reader user. We should have a meeting about what the expected order of content should be, even if we’re visually moving things around a bit with CSS grid.

The photographs here are beautifully shot. But some of them match the background color of the site… can we get away with alpha-transparent PNGs here? Those are always so big. Can any next-gen formats help us? Or should we try to match the background of a JPG with the background of the site seamlessly. Who’s writing the alt text for these?

There are some icons in use here. Inline SVG, right? Certainly SVG of some kind, not icon fonts, right? Should we build a whole icon system? I guess it depends on how we’re gonna be building this thing more broadly. Do we have a build system at all?

What’s the whole front-end plan here? Can I code this thing in vanilla HTML, CSS, and JavaScript? Well, I know I can, but what are the team expectations? Client expectations? Does it need to be a React thing because it’s part of some ecosystem of stuff that is already React? Or Vue or Svelte or whatever? Is there a CMS involved?

I’m glad the designer thought of not just the “desktop” and “mobile” sizes but also tackled an in-between size. Those are always awkward. There is no interactivity information here though. What should we do when that search field is focused? What gets revealed when that hamburger is tapped? Are we doing page-level transitions here?

I could go on and on. That’s how front-end developers think, at least in my experience and in talking with my peers.

A lot of those things have been our jobs forever though. We’ve been asking and answering these questions on every website we’ve built for as long as we’ve been doing it. There are different challenges on each site, which is great and keeps this job fun, but there is a lot of repetition too.

Allow me to get around to the title of this article. 

While we’ve been doing a lot of this stuff for ages, there is a whole pile of new stuff we’re starting to be expected to do, particularly if we’re talking about building the site with a modern JavaScript framework. All the modern frameworks, as much as they like to disagree about things, agree about one big thing: everything is a component. You nest and piece together components as needed. Even native JavaScript moves toward its own model of Web Components.

I like it, this idea of components. It allows you and your team to build the abstractions that make the most sense to you and what you are building.

Your Card component does all the stuff your card needs to do. Your Form component does forms how your website needs to do forms. But it’s a new concept to old developers like me. Components in JavaScript have taken hold in a way that components on the server-side never did. I’ve worked on many a WordPress website where the best I did was break templates into somewhat arbitrary include() statements. I’ve worked on Ruby on Rails sites with partials that take a handful of local variables. Those are useful for building re-usable parts, but they are a far cry from the robust component models that JavaScript frameworks offer us today.

All this custom component creation makes me a site-level architect in a way that I didn’t use to be. Here’s an example. Of course I have a Button component. Of course I have an Icon component. I’ll use them in my Card component. My Card component lives in a Grid component that lays them out and paginates them. The whole page is actually built from components. The Header component has a SearchBar component and a UserMenu component. The Sidebar component has a Navigation component and an Ad component. The whole page is just a special combination of components, which is probably based on the URL, assuming I’m all-in on building our front-end with JavaScript. So now I’m dealing with URLs myself, and I’m essentially the architect of the entire site. [Sweats profusely]

Like I told ya, a whole pile of new responsibility.

Components that are in charge of displaying content are almost certainly not hard-coded with data in them. They are built to be templates. They are built to accept data and construct themselves based on that data. In the olden days, when we were doing this kind of templating, the data has probably already arrived on the page we’re working on. In a JavaScript-powered app, it’s more likely that that data is fetched by JavaScript. Perhaps I’ll fetch it when the component renders. In a stack I’m working with right now, the front end is in React, the API is in GraphQL and we use Apollo Client to work with data. We use a special “hook” in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work? Is it some other kind of developer that specializes in this data layer work? No, it’s become the domain of the front-end developer.

Speaking of data, there is all this other data that a website often has to deal with that doesn’t come from a database or API. It’s data that is really only relevant to the website at this moment in time.

Which tab is active right now?

Is this modal dialog open or closed?

Which bar of this accordion is expanded?

Is this message bar in an error state or warning state?

How many pages are you paginated in?

How far is the user scrolled down the page?

Front-end developers have been dealing with that kind of state for a long time, but it’s exactly this kind of state that has gotten us into trouble before. A modal dialog can be open with a simple modifier class like <div class="modal is-open"> and toggling that class is easy enough with .classList.toggle(".is-open"); But that’s a purely visual treatment. How does anything else on the page know if that modal is open or not? Does it ask the DOM? In a lot of jQuery-style apps of yore, yes, it would. In a sense, the DOM became the “source of truth” for our websites. There were all sorts of problems that stemmed from this architecture, ranging from a simple naming change destroying functionality in weirdly insidious ways, to hard-to-reason-about application logic making bug fixing a difficult proposition.

Front-end developers collectively thought: what if we dealt with state in a more considered way? State management, as a concept, became a thing. JavaScript frameworks themselves built the concept right in, and third-party libraries have paved and continue to pave the way. This is another example of expanding responsibility. Who architects state management? Who enforces it and implements it? It’s not some other role, it’s front-end developers.

There is expanding responsibility in the checklist of things to do, but there is also work to be done in piecing it all together. How much of this state can be handled at the individual component level and how much needs to be higher level? How much of this data can be gotten at the individual component level and how much should be percolated from above? Design itself comes into play. How much of the styling of this component should be scoped to itself, and how much should come from more global styles?

It’s no wonder that design systems have taken off in recent years. We’re building components anyway, so thinking of them systemically is a natural fit.

Let’s look at our design again:

A bunch of new thoughts can begin!

Assuming we’re using a JavaScript framework, which one? Why? 

Can we statically render this site, even if we’re building with a JavaScript framework? Or server-side render it? 

Where are those recipes coming from? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it?

Maybe we should pick a CMS that has an API that will facilitate the kind of front-end building we want to do. Perhaps a headless CMS?

What are we doing for routing? Is the framework we chose opinionated or unopinionated about stuff like this?

What are the components we need? A Card, Icon, SearchForm, SiteMenu, Img… can we scaffold these out? Should we start with some kind of design framework on top of the base framework?

What’s the client state we might need? Current search term, current tab, hamburger open or not, at least.

Is there a login system for this site or not? Are logged in users shown anything different? 

Is there are third-party componentry we can leverage here?

Maybe we can find one of those fancy image components that does blur-up loading and lazy loading and all that.

Those are all things that are in the domain of front-end developers these days, on top of everything that we already need to do. Executing the design, semantics, accessibility, performance… that’s all still there. You still need to be proficient in HTML, CSS, JavaScript, and how the browser works. Being a front-end developer requires a haystack of skills that grows and grows. It’s the natural outcome of the web getting bigger. More people use the web and internet access grows. The economy around the web grows. The capability of browsers grows. The expectations of what is possible on the web grows. There isn’t a lot shrinking going on around here.

We’ve already reached the point where most front-end developers don’t know the whole haystack of responsibilities. There are lots of developers still doing well for themselves being rather design-focused and excelling at creative and well-implemented HTML and CSS, even as job posts looking for that dwindle.

There are systems-focused developers and even entire agencies that specialize in helping other companies build and implement design systems. There are data-focused developers that feel most at home making the data flow throughout a website and getting hot and heavy with business logic. While all of those people might have “front-end developer” on their business card, their responsibilities and even expectations of their work might be quite different. It’s all good, we’ll find ways to talk about all this in time.

In fact, how we talk about building websites has changed a lot in the last decade. Some of my early introduction to web development was through WordPress. WordPress needs a web server to run, is written in PHP, and stores it’s data in a MySQL database. As much as WordPress has evolved, all that is still exactly the same. We talk about that “stack” with an acronym: LAMP, or Linux, Apache, MySQL and PHP. Note that literally everything in the entire stack consists of back-end technologies. As a front-end developer, nothing about LAMP is relevant to me.

But other stacks have come along since then. A popular stack was MEAN (Mongo, Express, Angular and Node). Notice how we’re starting to inch our way toward more front-end technologies? Angular is a JavaScript framework, so as this stack gained popularity, so too did talking about the front-end as an important part of the stack. Node and Express are both JavaScript as well, albeit the server-side variant.

The existence of Node is a huge part of this story. Node isn’t JavaScript-like, it’s quite literally JavaScript. It makes a front-end developer already skilled in JavaScript able to do server-side work without too much of a stretch.

“Serverless” is a much more modern tech buzzword, and what it’s largely talking about is running small bits of code on cloud servers. Most often, those small bits of code are in Node, and written by JavaScript developers. These days, a JavaScript-focused front-end developer might be writing their own serverless functions and essentially being their own back-end developer. They’ll think of themselves as full-stack developers, and they’ll be right.

Shawn Wang coined a term for a new stack this year: STAR or Design System, TypeScript, Apollo, and React. This is incredible to me, not just because I kind of like that stack, but because it’s a way of talking about the stack powering a website that is entirely front-end technologies. Quite a shift.

I apologize if I’ve made you feel a little anxious reading this. If you feel like you’re behind in understanding all this stuff, you aren’t alone.

In fact, I don’t think I’ve talked to a single developer who told me they felt entirely comfortable with the entire world of building websites. Everybody has weak spots or entire areas where they just don’t know the first dang thing. You not only can specialize, but specializing is a pretty good idea, and I think you will end up specializing to some degree whether you plan to or not. If you have the good fortune to plan, pick things that you like. You’ll do just fine.

The only constant in life is change.

– Heraclitus     – Motivational Poster         – Chris Coyier

¹ I’m a white dude, so that helps a bunch, too. ↩️ ² Browsers speak a bunch more languages. HTTP, SVG, PNG… The more you know the more you can put to work! ↩️ ³ It’s an interesting bit of irony that WordPress websites generally aren’t built with client-side JavaScript components. ↩️

The post The Widening Responsibility for Front-End Developers appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

😉SiliconWebX | 🌐CSS-Tricks

[nonobo]

How the browser renders a web page? — DOM, CSSOM and Rendering

Whenever you are developing a website, there are certain things which are very essential for good user experience. from Pocket https://ift.tt/3aEk2Kx via IFTTT