#csswg | Explore Tumblr posts and blogs

jcmarchi · 1 month ago

Text

Support Logical Shorthands in CSS

New Post has been published on https://thedigitalinsider.com/support-logical-shorthands-in-css/

Support Logical Shorthands in CSS

There’s a bit of a blind spot when working with CSS logical properties concerning shorthands. Miriam explains:

Logical properties are a great way to optimize our sites in advance, without any real effort.

But what if we want to set multiple properties at once? This is where shorthands like margin and padding become useful. But they are currently limited to setting physical dimension. Logical properties are great, but they still feel like a second-class feature of the language.

There are a few 2-value shorthands that have been implemented, like margin-block for setting both the -block-start and -block-endmargins. I find those extremely useful and concise. But the existing 4-value shorthands feel stuck in the past. It’s surprising that a size shorthand can’t set the inline-size, and the inset shorthand doesn’t include inset-block-start. Is there any way to update those shorthand properties so that they can be used to set logical dimensions?

She ends with the money question, whether we can do anything about it. We’re currently in a position of having to choose between supporting flow-relative terms like block-start and inline-start with longhand properties and the ergonomic benefits of writing shorthand properties that are evaluated as physical terms like top, bottom, left, and right. Those of us writing CSS for a while likely have the muscle memory to adapt accordingly, but it’s otherwise a decision that has real consequences, particularly for multi-lingual sites.

Note that Miriam says this is something the CSS Working Group has been working on since 2017. And there’s a little momentum to pick it up and do something about it. The first thing you can do is support Miriam’s work — everything she does with the CSS Working Group (and it’s a lot) is a labor of love and relies on sponsorships, so chipping in is one way to push things forward.

The other thing you can do is chime into Miriam’s proposal that she published in 2021. I think it’s a solid idea. We can’t simply switch from physical to flow-relative terms in shorthand properties without triggering compatibility issues, so having some sort of higher-level instruction for CSS at the top of the stylesheet, perhaps as an at-rule that specifies which “mode” we’re in.

<coordinate-mode> = [ logical | physical ] or [ relative | absolute ] or ... @mode <coordinate-mode>; /* must come after @import and before any style rules */ @mode <coordinate-mode> <stylesheet> selector property: value !<coordinate-mode>;

Perhaps naming aside, it seems pretty reasonable, eh?

Direct Link →

0 notes

cleverhottubmiracle · 4 months ago

Link

[ad_1] The CSS Working Group (CSSWG) meets weekly (or close to it) to discuss and quickly resolve issues from their GitHub that would otherwise be lost in the back-and-forth of forum conversation. While each meeting brings interesting conversation, this past Wednesday (December 4th) was special. The CSSWG met to try and finally squash a debate that has been going on for five years: whether Masonry should be a part of Grid or a separate system. I’ll try to summarize the current state of the debate, but if you are looking for the long version, I recommend reading CSS Masonry & CSS Grid by Geoff and Choosing a Masonry Syntax in CSS by Miriam Suzanne. In 2017, it was frequently asked whether Grid could handle masonry layouts; layouts where the columns (or the rows) could hold unevenly sized items without gaps in between. While this is just one of several possibilities with masonry, you can think about the layout popularized by Pinterest: In 2020, Firefox released a prototype in which masonry was integrated into the CSS Grid layout module. The main voice against it was Rachel Andrew, arguing that it should be its own, separate thing. Since then, the debate has escalated with two proposals from Apple and Google, arguing for and against a grid-integrated syntax, respectively. There were some technical worries against a grid-masonry implementation that were since resolved. What you have to know is this: right now, it’s a matter of syntax. To be specific, which syntax is a. is easier to learn for authors and b. how might this decision impact possible future developments in one or both models (or CSS in general). In the middle, the W3C Technical Architecture Group (TAG) was asked for input on the issue which has prompted an effort to unify the two proposals. Both sides have brought strong arguments to the table over a series of posts, and in the following meeting, they were asked to lay those arguments once again in a presentation, with the hope of reaching a consensus. Remember that you can subscribe and read the full minutes on W3C.org The Battle of PowerPoints Alison Maher representing Microsoft and an advocate of implementing Masonry as a new display value, opened the meeting with a presentation. The main points were: Several properties behave differently between masonry and grid. Better defaults when setting display: masonry, something that Rachel Andrew recently argued for. There was an argument against display: masonry since fallbacks would be more lengthy to implement, whereas in a grid-integrated the fallback to grid is already there. Alison Maher refutes this since “needing one is a temporary problem, so [we] should focus on the future,” and that “authors should make explicit fallback, to avoid surprises.” “Positioning in masonry is simpler than grid, it’s only placed in 1 axis instead of 2.” Shorthands are also better: “Grid shorthand is complicated, hard to use. Masonry shorthand is easier because don’t need to remember the order.” “Placement works differently in grid vs masonry” and “alignment is also very different” There will be “other changes for submasonry/subgrid that will lead to divergences.” “Integrating masonry into grid will lead to spec bloat, will be harder to teach, and lead to developer confusion.” alisonmaher: “Conclusion: masonry should be a separate display type” Jen Simmons, representing the WebKit team and advocate of the “Just Use Grid” approach followed with another presentation. On this side, the main points were: Author learning could be skewed since “a new layout type creates a separate tool with separate syntax that’s similar but not the same as what exists […]. They’re familiar but not quite the same” The Chrome proposal would add around 10 new properties. “We don’t believe there’s a compelling argument to add so many new properties to CSS.” “Chromium argues that their new syntax is more understandable. We disagree, just use grid-auto-flow“ “When you layout rows in grid, template syntax is a bit different — you stack the template names to physically diagram the names for the rows. Just Use Grid re-uses this syntax exactly; but new masonry layout uses the column syntax for rows” “Other difference is the auto-flow — grid’s indicates the primary fill direction, Chrome believes this doesn’t make sense and changed it to match the orientation of lines” “Chrome argues that new display type allows better defaults — but the defaults propose aren’t good […] it doesn’t quite work as easily as claimed [see article] requires deep understanding of autosizing” “Easier to switch, e.g. at breakpoints or progressive enhancement” “Follows CSS design principles to re-use what already exists” The TAG review After two presentations with compelling arguments, Lea Verou (also a member of the TAG) followed with their input. lea: We did a TAG review on this. My opinion is fully reflected there. I think the arguments WebKit team makes are compelling. We thought not only should masonry be part of grid, but should go further. A lot of arguments for integrating is that “grid is too hard”. In that case we should make grid things easier. Complex things are possible, but simple things are not so easy. Big part of Google’s argument is defaults, but we could just have smarter defaults — there is precedent for this in CSS if we decided that would help ergonomics We agree that switching between grid vs. masonry is common. Grid might be a slightly better fallback than nothing, but minor argument because people can use @supports. Introducing all these new properties increasing the API surfaces that authors need to learn. Less they can port over. Even if we say we will be disciplined, experience shows that we won’t. Even if not intentional, accidental. DRY – don’t have multiple sources of truth One of arguments against masonry in grid is that grids are 2D, but actually in graphic design grids were often 1D. I agree that most masonry use cases need simpler grids than general grid use cases, but that means we should make those grids easier to define for both grid and masonry. The more we looked into this, we realize there are 3 different layout modes that give you 2D arrangement of children. We recommended not just make masonry part of grid, but find ways of integrating what we already have better could we come up with a shorthand that sets grid-auto-flow and flex-direction, and promote that for layout direction in general? Then authors only need to learn one control for it. The debate All was laid out onto the table, it was only left what other members had to say. oriol: Problem with Jen Simmons’s reasoning. She said the proposed masonry-direction property would be new syntax that doesn’t match grid-auto-flow property, but this property matches flex-direction property so instead of trying to be close to grid, tries to be close to flexbox. Closer to grid is a choice, could be consistent with different things. astearns: One question I asked is, has anyone changed their mind on which proposal they support? I personally have. I thought that separate display property made a lot more sense, in terms of designing the feature and I was very daunted by the idea that we’d have to consider both grid and masonry for any new development in either seemed sticky to me but the TAG argument convinced me that we should do the work of integrating these things. TabAtkins: Thanks for setting that up for me, because I’m going to refute the TAG argument! I think they’re wrong in this case. You can draw a lot of surface-level connections between Grid and Masonry, and Flexbox, and other hypothetical layouts but when you actually look at details of how they work, behaviors each one is capable of, they’re pretty distinct if you try to combine together, it would be an unholy mess of conflicting constraints — e.g. flexing in items of masonry or grid or you’d have a weird mish-mash of, “the 2D layout. But if you call it a flex you get access to these properties, call it grid, access to these other properties concrete example, “pillar” example mentioned in webKit blog post, that wasn’t compatible with the base concepts in masonry and flex because it wants a shared block formatting context grid etc have different formatting contexts, can’t use floats. lea: actually, the TAG argument was that layout seems to actually be a continuum, and syntax should accommodate that rather than forcing one of two extremes (current flex vs current grid). The debate kept back and forth until there was an attempt to set a general north star to follow. jyasskin: Wanted to emphasize a couple aspects of TAG review. It seems really nice to keep the property from Chrome proposal that you don’t have to learn both, can just learn to do masonry without learning all of Grid even if that’s in a unified system perhaps still define masonry shorthand, and have it set grid properties jensimmons: To create a simple masonry-style layout in Grid, you just need 3 lines of code (4 with a gap). It’s quite simple. jyasskin: Most consensus part of TAG feedback was to share properties whenever possible. Not necessary to share the same ‘display’ values; could define different ‘display’ values but share the properties. One thing we didn’t like about unified proposal was grid-auto-flow in the unified proposal, where some values were ignored. Yeah, this is the usability point I’m pounding on Another Split Decision Despite all, it looked like nobody was giving away, and the debate seemed stuck once again: astearns: I’m not hearing a way forward yet. At some point, one of the camps is going to have to concede in order to move this forward. lea: What if we do a straw poll. Not to decide, but to figure out how far are we from consensus? The votes were cast and the results were… split. florian: though we could still not reach consensus, I want to thank both sides for presenting clear arguments, densely packed, well delivered. I will go back to the presentations, and revisit some points, it really was informative to present the way it was. That’s all folks, a split decision! There isn’t a preference for either of the two proposals and implementing something with such mixed opinions is something nobody would approve. After a little over five years of debate, I think this meeting is yet another good sign that a new proposal addressing the concerns of both sides should be considered, but that’s just a personal opinion. To me, masonry (or whatever name it may be) is an important step in CSS layout that may shape future layouts, it shouldn’t be rushed so until then, I am more than happy to wait for a proposal that satisfies both sides. Further Reading Relevant Issues [ad_2] Source link

0 notes

fahrni · 6 months ago

Text

Saturday Morning Coffee

Good morning from Charlottesville, Virginia! ☕️

Were four days away from what is the most consequential Presidential vote in my lifetime, perhaps the country’s lifetime.

Voting is the most important thing you can do to save our democracy.

I’ll leave it at that. I hope you enjoy the links.

Pema Levy • Mother Jones

Donald Trump may be a known quantity. He’s been a public figure for decades, a television star, and president from 2017-2021. But a second Trump term would present something the United States has never experienced before. Not a would-be authoritarian in the White House—that was Trump’s first term—but a would-be authoritarian who could actually accomplish the task of transforming the federal government into a tool of political repression.

Don’t vote for this man. He’ll destroy our country as we know it and turn it into a hellscape.

Sascha Pare • Live Science

High school students who came up with ‘impossible’ proof of Pythagorean theorem discover 9 more solutions to the problem

I love that a couple of high school kids figured these proofs out. Good for them!

Dave Winer • Scripting News

I’m searching for some common ground between the twitter-like systems, a basis for interop, a common API even. We had that for the blogging layer of this onion, something called the MetaWeblog API. All the popular blogging software supported it. And that meant you could write once and publish to many places. And you could write the script that did that in an afternoon or two. We started out with simple systems and the best of intentions. There’s no technical barrier. And we could do it in a few weeks at most if there was a will to do it.

I have thoughts around this as well that are built around Dave’s desire to use RSS to populate the various services. It deserves a blog post all its own. Maybe I’ll have enough gumption to do that someday. 😃

Matt Carroll • Flock

Over the years, Flutter has attracted millions of developers who built user interfaces across every platform. Flutter began as a UI toolkit for mobile - iOS and Android, only. Then Flutter added support for web. Finally, Flutter expanded to Mac, Windows, and Linux. Across this massive expansion of scope and responsibility, the Flutter team has only marginally increased its size. To help expand Flutter’s available labor, and accelerate development, we’re creating a fork of Flutter, called Flock.

This feels extremely ambitious to me and I fear it’ll fail. Hopefully it doesn’t cause a mess in the community.

Sidney Blumenthal • The Guardian

Donald Trump keeps saying that if he is elected to a second term he will prosecute his political opponents, “the enemies within”. On 22 October he stated, once again, that as president he would use “extreme power … We can’t play games with these people. These are people that are dangerous people … an enemy from within.”

This man is a menace and must be defeated once and for all. Kick him to the curb so, hopefully, he’ll get the idea he’s not wanted and go play golf for the rest of his miserable life.

Iain Thomson • The Register

Drivers passing through San Francisco have a new roadside distraction to consider: billboards calling out businesses that don’t cough up for the open source code that they use.

Some open source projects thrive and some struggle. If more companies would dedicate some resources to these projects it would be better for everyone involved. We don’t need more incidents like the person who snuck a back door into an open source project or just see them abandoned and left to bit rot.

Ahmad Shadeed

Currently, the CSS Working Group (CSSWG) is discussing whether to include masonry as part of CSS grid, or as a new layout module?

I like this, especially if the author(s) of masonry agree with the idea.

Louie Mantia

I wish there were more browsers, and I wish they were more unique. I appreciate that Arc attempted to innovate, but their ego and hubris are a little frustrating. They believe their product is so great that everyone should use it, including their own family and friends. However, when they don’t, they are left feeling perplexed.

I know lots of folks at work using Arc and they love it! I’m skeptical of it. Not because it’s different but because it’s built on Chromium and I don’t trust Google.

Tim Anderson • Dev Class

A Google engineer presented a proposal to the official standardization committee that would split JavaScript into two languages, a core to be implemented by runtime engines and a more capable variant which depends on tools that compile it down to that core.

I thought the idea of a core was Web Assembly? Maybe that’s too broad? I’d like to know more about what this proposal implies and how would it affect developers.

Michael Miszczak • Just a Pack

A couple of weeks ago, in a moment of caffeinated inspiration/despair, I sat down and wrote a long Facebook post as to why we were ditching Google and switching to DuckDuckGo. Today I want to dive even deeper into this topic, and give you a first-hand account of how Google is killing hundreds of thousands of blogs and small publishers.

Blogs were never really meant to be monetized but enterprising folks have figured out a way to do it.

Unfortunately relying on an advertising company’s search engine to surface your blog to users is risky, as the article points out.

My blog is for me and the ten folks who read it. It’s an outlet. Thankfully I don’t have to make a living from it. I’d starve.

Emma Roth • The Verge

Though Dorsey’s message didn’t specify how many employees would be laid off, sources told Fortune that it could be around 100 employees — or about a quarter of Tidal’s remaining staff. Tidal cut 10 percent of its workers last December, and Dorsey reportedly considered a major reorganization at Block in July.

A few years back, during COVID summer, I tried Tidal, Spotify, and Apple Music. Tidal isn’t bad at all. It’s another competitor in the big music service scene. Granted, it’s the smaller of the three, but the user experience at the time was perfectly fine and the music sounded just fine.

I landed on Apple Music, which has the worst user experience, because it is bundled as part of Apple One. It’s fine.

0 notes

ryotarox · 6 years ago

Photo

([css-writing-modes] Support rtl Chinese · Issue #2754 · w3c/csswg-drafts · GitHubから)

But Japanese commas and period include a blank right half, and that blank feels very weird to me if writing in RTL. When switching to a vertical text, the blank upper half is removed and replaced by a blank lower half to keep the comma / period next to the preceeding phrase and away from the following phrase. Independently of the shape of the punctuation mark, I'd expect something similar to happen to the spacing in RTL mode.

Yep, i was wondering those things too. It could also be that the tendency to leave the gap to the right in Japanese punctuation is a new thing, too. The idea that RTL text in Japanese is and always was only for short pieces of text is supported by the article at https://www.sljfaq.org/afaq/right-to-left.html.

https://upload.wikimedia.org/wikipedia/commons/f/f6/RIKEN_VITAMIN.png

- - - - - - - - - - - - - - - -

和文横書きの本文で書字方向がRTLの時の句読点のアキをどうすべきか問題。

7 notes · View notes

azcode · 2 years ago

Link

0 notes

suzanneshannon · 4 years ago

Text

Proposal for CSS @when

CSS is on a tear lately. Again, I’ve heard of a brand new thing I’ve never seen before, and again it’s via Miriam: CSS Conditionals.

🎉 CSSWG just resolved to adopt @tabatkins when/else proposal into the next level of CSS Conditionals. Here's the proposal:https://t.co/IXEOK7xKcL

— Miriam (But Terrible) (@TerribleMia) September 15, 2021

There is already such a thing as logic in media queries. In fact, a media query is already logic.

@media (min-width: 600px) { /* WHEN this media query is true, do these styles. */ }

And if you want to have styles that are mutually exclusive to the above, you’d write two media queries:

@media (min-width: 600px) { /* ... */ } @media (max-width: 599px) { /* ... */ }

That’s a little�� fidgety. The syntax is much cleaner in this new proposal:

@when media(min-width: 600px) { /* ... */ } @else { /* ... */ }

Looks like you can do multiple conditions via and, have a waterfall logic stack with multiple @else statements, and not just use @media, but @supports as well.

@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) { /* A */ } @else supports(caret-color: pink) and supports(background: double-rainbow()) { /* B */ } @else { /* C */ }

Looks very logical and handy to me!

I saw one little squabble about the naming. @if could be a logical name here too. But Sass uses @if and it would be super annoying to a ton of developers if they had to refactor all their Sass logic to something new or however that would fall out. Should CSS cede to any preprocessor out there? Nah, but Sass has been around a long time and is super popular, and there is a perfectly good alternative, so why cause the pain? In that thread, it’s not just about Sass either — some folks think @when is a better name anyway.

The post Proposal for CSS @when appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Proposal for CSS @when published first on https://deskbysnafu.tumblr.com/

0 notes

epubresearch · 5 years ago

Link

0 notes

dorothydelgadillo · 6 years ago

Text

Designing An Aspect Ratio Unit For CSS

Rachel Andrew

2019-03-11T15:00:41+01:002019-03-11T14:48:12+00:00

One of the things that comes up again and again in CSS is the fact that there is no way to size things based on their aspect ratio. In particular when working with responsive designs, you often want to be able to set the width to a percentage and have the height correspond to some aspect ratio. This is something that the body responsible for designing CSS - the CSS Working Group (CSSWG) have been discussing recently and, at the recent CSSWG meeting in San Francisco a proposed solution was agreed on.

This is a new resolution so we have no browser implementations yet, but I thought it worth writing up the proposal, in case anyone in the wider web community could see a showstopping issue with it. It also gives something of an insight into the work of the CSSWG and how issues like this are discussed, and new features designed.

What Is The Problem We Are Trying To Solve?

The issue in in regard to non-replaced elements, which do not have an intrinsic aspect ratio. Replaced elements are things like images or a video placed with the <video> element. They are different to other boxes in CSS as they have set dimensions, and their own behavior. These replaced elements are said to have an intrinsic aspect ratio, due to them having dimensions.

A div or some other HTML element which may contain your content has no aspect ratio, you have to give it a width and a height. There is no way to say that you want to maintain a 16 / 9 aspect ratio, and that whatever the width is, the height should be worked out using the given aspect ratio.

A very common situation is when you want to embed an iframe in order to display a video from a video sharing site such as YouTube. If you use the <video> element then the video has an aspect ratio, just like an image. This isn’t the case if the video is elsewhere and you are using an embed. What you want is for your video to be responsive, yet remain at the correct aspect ratio for the video. What you get however, if you set width to 100%, is the need to then set a height. Your video ends up stretched or squished.

Let’s also look at a really simple case of creating a grid layout with square cells. If we were using fixed column track sizes then it is easy to get our square cells as we can define rows to be the same size as the column tracks. We could also make our row tracks auto sized, and have items and set the height on the items.

See the Pen Aspect Ratios Example 1 by Rachel Andrew.

The problem comes when we want to use auto-fill, and fill a container with as many column tracks as will fit. We now can’t simply give the items a height, as we don’t know what the width is. Our items are no longer square.

See the Pen Aspect Ratios Example 2 by Rachel Andrew.

Being able to size things based on their aspect ratio would mean we could calculate the correct aspect ratio once the grid item is laid out. Thus making the grid items as tall as they are wide, so that they always maintain as a square no matter what their width.

Current Aspect Ratio Solutions

Web developers have been coping with the lack of any aspect ratio in CSS in various ways, the main one being the “padding hack”. This solution uses the fact that padding % in the block direction (so top and bottom padding in a horizontal top to bottom language) is calculated from the inline size (width).

The article Aspect Ratio Boxes on CSS Tricks has a good rundown of the current methods of creating aspect ratio boxes. The padding hack works in many cases but does require a bunch of hoops to jump through in order to get it working well. It’s also not in the slightest bit intuitive - even if you know why and how it works. It’s those sort of things that we want to try and solve in the CSS Working Group. Personally I feel that the more we get elegant solutions for layout in CSS, the more the messy hacks stand out as something we should fix.

For the video situation you can use JavaScript, and a very popular solution is to use FitVids, as also described in the CSS Tricks article. Using JavaScript is a reasonable solution but it’s more script to load, and also something else to remember to do. You can’t simply plonk a video into your content and it just work.

The Proposed Solution

What we are looking for is a generic solution that will work for regular block layout, such as a video in an iframe, or a div on the page. It should also work if the item is a grid or flex item. There is a different issue of wanting grid tracks to maintain an aspect ratio (having the row tracks match the columns), this solution would fix many cases however where you might want that. You would be working from the item out rather than the track in however.

The soluion will be part of the CSS Sizing Specification, and is being written up in the CSS Sizing 4 specification. This is the first step for new features being designed by the CSS Working Group, the idea is discussed, and then written up in a specification. An initial proposal for this feature was brought to the group by Jen Simmons, and you can see her slide deck which goes through many of the use cases discussed in this article here.

The new property introduced to the Sizing specification is be the aspect-ratio property. This property will accept a value which is an aspect ratio such as 16/9. For example, if you want a square box with the width the same as the height you would use the following:

.box { width: 400px; height: auto; aspect-ratio: 1/1; }

For a 16 / 9 box, such as for a video:

.box { width: 100%; height: auto; aspect-ratio: 16/9; }

For the example with the square items in a grid layout, we leave our grid tracks auto sized, which means they will take their size from the items, we then make our items sized with the aspect-ratio unit.

.grid { display: grid; grid-template-columns: repeat(autofill, minmax(200px, 1fr)); } .item { aspect-ratio: 1/1; }

Features often go through various iterations before browsers start to implement them. Having discussed the need for an aspect ratio unit previously, this time we were looking at one particular concern around the proposal. What happens if you specify an aspect ratio box, but then add too much content to the box? This same issue is brought up in the CSS Tricks article about the padding hack, with equally unintuitive solutions required to fix it.

Dealing With Overflow

What we are dealing with here is overflow, as is so often the case on the web. We want to have a nice neatly sized box, our design asks for a nice neatly sized box, our content is less well behaved and turns out to be bigger than we expected and breaks out of the box. In addition to specifying how we ask for an aspect ratio in one dimension, we also have to specify what happens if there is too much content, and how the web developer can tell the browser what to do about that overflow content.

There is a general design principal in CSS that we try to avoid data loss. Data loss in a CSS context is where some of your content vanishes. That might either be because it gets poked off the side of the viewport, or is cropped when it overflows. It’s generally preferable to have a messy overflow, as you will notice it and do something about it. If we cause something to vanish, you may not realise, especially if it only happens at one breakpoint.

We have a similar issue in grid layout which is nicely fixed with the minmax() function for track sizes. You can define grid tracks with a fixed height using a length unit. This will give you a lovely neat grid of boxes, however as soon as someone adds more content than you expected into one of those boxes, you will get overflow.

See the Pen Aspect Ratios Example 3 by Rachel Andrew.

The fix for this in grid layout is to use minmax() for your track size, and make the max value auto. In this case auto can be thought of as “big enough to fit the content”. What you then get is a set of neat looking boxes that, if more content that expected gets in, grow to accept that content. Infinitely better than a messy overflow or cropped content. In the example below you can see the first row with the box with extra content has grown, the second row is sized at 100 pixels.

See the Pen Aspect Ratios Example 4 by Rachel Andrew.

We need something similar for our aspect ratio boxes, and the suggestion turns out to be relatively straightforward. If you do nothing about overflow, then the default behavior will be that the content is allowed to grow past the height that is inferred by the aspect ratio. This will give you the same behavior as the grid tracks sized with minmax(). In the case of a height, the height will be at least the height defined by the aspect ratio, but if the content is taller, the height can grow to fit it.

If you don’t want that, then you can change the value of overflow as you would normally do. For example hiding the overflow, or allowing it to scroll.

Commenting On Proposals In Progress

I think that this proposal covers the use cases detailed in the CSS Tricks article, and the common things that web developers want to do. It gives you a way to create aspect ratio sized boxes in various layout contexts, and is robust. It will cope with the real situation of content on the web, where we don’t always know how much content we have or how big it is.

If you spot some real problem with this, or have some other use case that you think can’t be solved, you can comment on the proposal directly by raising an issue at the CSSWG GitHub repo. If you don’t want to do that you can always comment here, or post to your own blog and link to it here so I can see it. I’d be very happy to share your thoughts with the working group as this feature is discussed.

(il)

0 notes

jcmarchi · 3 months ago

Text

The Mistakes of CSS

New Post has been published on https://thedigitalinsider.com/the-mistakes-of-css/

The Mistakes of CSS

Surely you have seen a CSS property and thought “Why?” For example:

Why doesn’t z-index work on all elements, and why is it “-index” anyways?

Or:

Why do we need interpolate-size to animate to auto?

You are not alone. CSS was born in 1996 (it can legally order a beer, you know!) and was initially considered a way to style documents; I don’t think anyone imagined everything CSS would be expected to do nearly 30 years later. If we had a time machine, many things would be done differently to match conventions or to make more sense. Heck, even the CSS Working Group admits to wanting a time-traveling contraption… in the specifications!

NOTE: If we had a time machine, this property wouldn’t need to exist.

CSS Values and Units Module Level 5, Section 10.4

If by some stroke of opportunity, I was given free rein to rename some things in CSS, a couple of ideas come to mind, but if you want more, you can find an ongoing list of mistakes made in CSS… by the CSS Working Group! Take, for example, background-repeat:

Not quite a mistake, because it was a reasonable default for the 90s, but it would be more helpful since then if background-repeat defaulted to no-repeat.

Right now, people are questioning if CSS Flexbox and CSS Grid should share more syntax in light of the upcoming CSS Masonry layout specifications.

Why not fix them? Sadly, it isn’t as easy as fixing something. People already built their websites with these quirks in mind, and changing them would break those sites. Consider it technical debt.

This is why I think the CSS Working Group deserves an onslaught of praise. Designing new features that are immutable once shipped has to be a nerve-wracking experience that involves inexact science. It’s not that we haven’t seen the specifications change or evolve in the past — they most certainly have — but the value of getting things right the first time is a beast of burden.

Direct Link →

0 notes

mbaljeetsingh · 7 years ago

Text

CSS Logical Properties

Since the beginning of the web we have been used to deal with physical CSS properties for different features, for example we all know how to set a margin in an element using margin-left, margin-right, margin-top and/or margin-bottom. But with the appearance of CSS Writing Modes features, the concepts of left, right, top and bottom have somehow lost their meaning.

Imagine that you have some right-to-left (RTL) content on your website your left might be probably the physical right, so if you are usually setting margin-left: 100px for some elements, you might want to replace that with margin-right: 100px. But what happens if you have mixed content left-to-right (LTR) and RTL at the same time, then you will need different CSS properties to set left or right depending on that. Similar issues are present if you think about vertical writing modes, maybe left for that content is the physical top or bottom.

CSS Logical Properties and Values is a CSS specification that defines a set of logical (instead of physical) properties and values to prevent this kind of issues. So when you want to set that margin-left: 100px independently of the direction and writing mode of your content, you can directly use margin-inline-start: 100px that will be smart enough. Rachel Andrew has a nice blog post explaining deeply this specification and its relevance.

Example of margin-inline-start: 100px in different combinations of directions and writing modes

Oriol Brufau, an active collaborator on the CSS Working Group (CSSWG), has been doing a Igalia Coding Experience implementing support for CSS Logical Properties and Values in Blink and WebKit. Maybe you were already aware of this as my colleague Frédéric Wang already talked about it in his last blog post reviewing the activities of Igalia Web Platform team in the past semester.

Some history

Chromium and WebKit have had support since a long time ago for some of the CSS logical properties defined by the spec. But they were not using the standard names defined in the specification but some -webkit- prefixed ones with different names.

For setting the dimensions of an element Chromium and WebKit have properties like -webkit-logical-width and -webkit-logical-height. However CSS Logical defines inline-size and block-size instead. There are also the equivalent ones for minimum and maximum sizes too. These ones have been already unprefixed at the beginning of 2017 and included in Chromium since version 57 (March 2017). In WebKit they are still only supported using the prefixed version.

But there are more similar properties for margins, paddings and borders in Chromium and WebKit that use start and end for inline direction and before and after for block direction. In CSS Logical we have inline-start and inline-end for inline direction and block-start and block-end for block direction, which are much less confusing. There was an attempt in the past to unprefix these properties but the work was abandoned and never completed. These ones were still using the -webkit- prefix so we decided to tackle them as the first task.

The post has been only talking about properties so far, but the same thing applies to some CSS values, that is why the spec is called CSS Logical Properties and Values. For example a very well-known property like float has the physical values left and right. The spec defines inline-start and inline-end as the logical values for float. However these were not supported yet in Chromium and WebKit, not even using -webkit- prefixes.

Firefox used to have some -moz- prefixed properties, but since Firefox 41 (September 2015) it is shipping many of the standard logical properties and values. Firefox has been using these properties extensively in its own tests, thus having them supported in Chromium will make easier to share them.

At the beginning of this work, Oriol wrote a document in which explaining the implementation plan where you can check the status of all these properties in Chromium and Firefox.

Unprefix existent properties

We originally send an intent to implement and ship for the whole spec, actually not all the spec but the parts that the CSSWG considered ready to implement. But Chromium community decided it was better to split it in two parts:

The work on the first part, making the old -webkit- prefixed properties to use the new standard names, has been already completed by Oriol and it is going to be included in the upcoming release of Chromium 69.

In addition to the Chromium work Oriol has just started to do this on WebKit too. Work is on early stages here but hopefully things will move forward in parallel to the Chromium stuff.

Adding support for the rest

Next step was to add support for the new stuff behind an experimental flag. This work is ongoing and you can check the current status in the latest Canary enabling the Experimental Web Platform features flag.

So far Oriol has added support for a bunch of shorthands and the flow-relative offset properties. You can follow the work in issue #850004 in Chromium bug tracker.

We will talk more about this in a future blog post once this task is completed and the new logical properties and values are shipped.

Tests!

Of course testing is a key part of all these tasks, and web-platform-tests (WPT) repository plays a fundamental role to ensure interoperability between the different implementations. Like we have been doing in Igalia lately in all our developments we used WPT as the primary place to store all the tests related to this work.

Oriol has been creating tests in WPT to cover all these features. Initial tests were based in the ones already available in Firefox and modified them to adapt to the rest of stuff that needs to be checked.

Note that in Chromium all the sideways writing modes test cases are failing as there is no support for sideways in Chromium yet.

Plans for the future

As explained before, this is an ongoing task but we already have some extra plans for it. These are some of the tasks (in no particular order) that we would like to do in the coming months:

Complete the implementation of CSS Logical Properties and Values in Chromium. This was explained in the previous point and is moving forward at a good pace.

Get rid of usage of -webkit- prefixed properties in Chromium source code. Oriol has also started this task and is currently work in progress.

Deprecate and remove the -webkit- prefixed properties. It still too early for that but we will keep an eye on the metrics and do it once usage has decreased.

Implement it in WebKit too, first by unprefixing the current properties (which has been already started) and later continuing with the new things. It would be really nice if WebKit follows Chromium on this. Edge also has plans to add support for this spec, so that would make logical properties and values available in all the major browsers.

Wrap up

Oriol has been doing a good job here as part of his Igalia Coding Experience. Apart from all the new stuff that is landing in Chromium, he has also been fixing some related bugs.

We have just started the WebKit tasks, but we hope all this work can be part of future Chromium and Safari releases in the short term.

And that is all for now, we will keep you posted! 😉

via CSS-Tricks https://ift.tt/2LgPO1X

#IFTTT #Feedly

0 notes

sebastianlenton · 5 years ago

Link

You know how leading always felt kind of broken/weird in web typography? Yeah, that’s because it is. The CSSWG is working on fixing it permanently — specifically @fantasai with the support of Microsoft Design. Read about how it will work in the future: https://t.co/FUVABCat7W

— Jen Simmons (@jensimmons) August 19, 2020

#IFTTT #Twitter

0 notes

douglassmiith · 5 years ago

Text

Crowdfunding Web Platform Features With Open Prioritization

About The Author

Rachel Andrew is not only Editor in Chief of Smashing Magazine, but also a web developer, writer and speaker. She is the author of a number of books, including … More about Rachel Andrew …

Rachel Andrew takes a look at a new effort to crowdfund the costs of implementing browser features.

In my last post, I described some interesting CSS features — some of which are only available in one browser. Most web developers have some feature they wish was more widely available, or that was available at all. I encourage developers to use, talk about, and raise implementation bugs with browsers to try to get features implemented, however, what if there was a more direct way to do so? What if web developers could get together and fund the development of these features?

This is the model that open-source consultancy Igalia is launching with their Open Prioritization experiment. The basic idea is a crowdfunding model for web platform features. If we want a feature implemented, we can put in a small amount of money to help fund that work. If the goal is reached, the feature can be implemented. This article is based on an interview with Brian Kardell, Developer Advocate at Igalia.

What Is Open Prioritization?

The idea of open prioritization is that the community gets to choose and help fund feature development. Igalia have selected a list of target features, all of which are implemented or currently being implemented in at least one engine. Therefore, funding a feature will help it become available cross-browser, and more usable for us as developers. The initial list is:

CSS lab( ) colors in Firefox

:focus-visible in WebKit/Safari

HTML inert in WebKit/Safari

Selector list arguments for :not( ) in Chrome

CSS Containment support in WebKit/Safari

CSS d (SVG path) support in Firefox

The website gives more explanation of each feature and all of the details of how the funding will work. Igalia are working with Open Collective to manage the pledges.

Who Are Igalia?

You may never have heard of Igalia, but you will have benefited from their work. Igalia works on browser engines, and have specialist knowledge of all of the engines. They had the second-highest number of commits to the Chrome and WebKit source in 2019. If you love CSS Grid Layout, then you have Igalia to thank for the implementation in Chrome and WebKit. The work to add the feature to those browsers was done by a team at Igalia, rather than engineers working internally at the browser company.

This is what makes this idea so compelling. It isn’t a case of raising some money and then trying to persuade someone to do the work. Igalia have a track record of doing the work. Developers need to be paid, so by crowdsourcing the money we are able to choose what is worked on next. Igalia also already have the relationships with the engines to make any suggested feature likely to be a success.

Will Browsers Accept These Features If We Fund Them?

The fact that Igalia already have relationships within browser engine teams, and have already discussed the selected features with them means that if funded, we should see the features in browsers. And, there are already precedents for major features being funded by third parties and developed by Igalia. The Grid Layout implementation in Chrome and WebKit was funded by Bloomberg Tech. They were frustrated by the lack of Grid Layout implementation, and it was Bloomberg Tech who provided the money to develop that feature over several years.

Chrome and WebKit were happy to accept the implementation; there was no controversy over adding the feature. Rather, it was a matter of prioritization. The browsers had other work that was deemed a higher priority, and financial commitment and developer time was therefore directed elsewhere. The features that have been selected for this initial crowdfunding attempt are also non -controversial in terms of their implementation. If the work can be done then the engines are likely to accept it. Interoperability — things working in the same way across browsers — is something all browser vendors care about. There is no benefit to an engine to lag behind. We essentially just get to bypass the internal prioritization process for the feature.

Why Don’t Browsers Just Do This Stuff?

I asked Brian why the browser companies don’t fund these things themselves. He explained,

“People might think, for example, ‘Apple has all of the money in the world’ but this ignores complex realities. Apple’s business is not their Web browser. In fact, the web browser itself isn’t a money-making endeavor for anyone. Browsers and standards are voluntary, they are a commons. Cost-wise, however, browsers are considerable. They are massively more complex than most of us realize. Only 3 organizations today have invested the many years and millions of dollars annually that it takes to evolve and maintain a rendering engine project. Any one of them is already making a massive and unparalleled investment in the commons.”

Brian went on to point out the considerable investment of Firefox into Servo, and Google into LayoutNG, projects which will improve the browser experience and also make it possible to implement new features of the platform. There is a lot that any browser could be implementing in their engine, but the way those features are internally prioritized may not always map to our needs as developers.

It occurred to me that by funding browser implementation, we are doing the same thing that we do for other products that we use. Many of us will have developed a plugin for a needed feature in a CMS or paid a third party to provide it. The CMS developers spend their time working on the core product, ensuring that it is robust, secure, and up to date. Without the core product, adding plugins would be impossible. Third parties however can contribute parts to that platform, and in a sense that is what we can do via open prioritization. Show that a feature is worthwhile enough for us to pledge some cash to get it over the line.

How Does This Fit With Projects Such As Web We Want?

SmashingConf has supported the Web We Want project, where developers pitched web platform ideas to be discussed and voted for onstage at conferences. I was involved in several of these events as a host and on the panel. I wondered how open prioritization fits with these existing efforts. Brian explained that these are quite different things saying,

“… if you asked me what could make my house better I could name a million things. Some of those aren’t even remotely practical, they would just be really neat. But if you said make a list of things you could do with a budget for what each one costs — my list will be considerably more practical and bound by realities I know exist.

At the end of the month if you say “there is your list, and here is $100, what will you do with it?” that’s a very direct question that helps me accomplish something practical. Maybe I will paint. Maybe I will buy some new lighting. Or, maybe I will save it for some months toward something more costly.”

The Web We Want project asks an open question, it asks what we want of the platform. Many of the wants aren’t things that already exist as a specification. To actually start to implement any of these things would mean starting right at the beginning, with an idea that needs taking right from the specification stage. There are few certainties, and they would be very hard to put a price on.

The features selected for this first open prioritization experiment are deliberately limited in scope. They already have some implementation; they have a specification, and Igalia have already spoken to browser maintainers to check that the features are ready to work on but don’t feature in immediate priorities.

Supporting this project means supporting a concrete chunk of development, that can happen within a reasonably short timeframe. Posting an idea to Web We Want, writing up an idea on your blog, or adding an issue describing a totally new feature on the CSSWG GitHub repo potentially gets a new idea out into the discussion. However, those ideas may have a long slow path to becoming reality. And, given the nature of standards discussions, probably won’t happen in exactly the way that you imagined. It is valuable to propose these things, but very hard to estimate time and costs to a final implementation.

The same problem is true for the much-wanted feature of container queries, Igalia have gone so far as to mention container queries in their FAQ. Container queries are something that many people involved in the standards process and at browser vendors are looking into, however, those discussions are at an early stage. It isn’t something it would be possible to put a monetary value on at this point.

Get Involved!

There is more information at the Open Prioritization site, along with a detailed FAQ answering other questions that you might have. I’m excited about this because I’m always keen to help find ways for designers and developers to get involved in the web platform. It is our platform. We can wait for things to be granted to use by browser vendors, or we can actively contribute via ideas, bug reports, and with Open Prioritization a bit of cash, to help to make it better.

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

Via http://www.scpie.org/crowdfunding-web-platform-features-with-open-prioritization/

source https://scpie.weebly.com/blog/crowdfunding-web-platform-features-with-open-prioritization

0 notes

laurelkrugerr · 5 years ago

Text

Crowdfunding Web Platform Features With Open Prioritization

About The Author

Rachel Andrew is not only Editor in Chief of Smashing Magazine, but also a web developer, writer and speaker. She is the author of a number of books, including … More about Rachel Andrew …

Rachel Andrew takes a look at a new effort to crowdfund the costs of implementing browser features.

What Is Open Prioritization?

CSS lab( ) colors in Firefox

:focus-visible in WebKit/Safari

HTML inert in WebKit/Safari

Selector list arguments for :not( ) in Chrome

CSS Containment support in WebKit/Safari

CSS d (SVG path) support in Firefox

The website gives more explanation of each feature and all of the details of how the funding will work. Igalia are working with Open Collective to manage the pledges.

Who Are Igalia?

Will Browsers Accept These Features If We Fund Them?

Why Don’t Browsers Just Do This Stuff?

I asked Brian why the browser companies don’t fund these things themselves. He explained,

How Does This Fit With Projects Such As Web We Want?

Get Involved!

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/crowdfunding-web-platform-features-with-open-prioritization/ source https://scpie1.blogspot.com/2020/07/crowdfunding-web-platform-features-with.html

0 notes

riichardwilson · 5 years ago

Text

Crowdfunding Web Platform Features With Open Prioritization

About The Author

Rachel Andrew is not only Editor in Chief of Smashing Magazine, but also a web developer, writer and speaker. She is the author of a number of books, including … More about Rachel Andrew …

Rachel Andrew takes a look at a new effort to crowdfund the costs of implementing browser features.

What Is Open Prioritization?

CSS lab( ) colors in Firefox

:focus-visible in WebKit/Safari

HTML inert in WebKit/Safari

Selector list arguments for :not( ) in Chrome

CSS Containment support in WebKit/Safari

CSS d (SVG path) support in Firefox

The website gives more explanation of each feature and all of the details of how the funding will work. Igalia are working with Open Collective to manage the pledges.

Who Are Igalia?

Will Browsers Accept These Features If We Fund Them?

Why Don’t Browsers Just Do This Stuff?

I asked Brian why the browser companies don’t fund these things themselves. He explained,

How Does This Fit With Projects Such As Web We Want?

Get Involved!

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/crowdfunding-web-platform-features-with-open-prioritization/ source https://scpie.tumblr.com/post/623543113348251648

0 notes

scpie · 5 years ago

Text

Crowdfunding Web Platform Features With Open Prioritization

About The Author

Rachel Andrew is not only Editor in Chief of Smashing Magazine, but also a web developer, writer and speaker. She is the author of a number of books, including … More about Rachel Andrew …

Rachel Andrew takes a look at a new effort to crowdfund the costs of implementing browser features.

What Is Open Prioritization?

CSS lab( ) colors in Firefox

:focus-visible in WebKit/Safari

HTML inert in WebKit/Safari

Selector list arguments for :not( ) in Chrome

CSS Containment support in WebKit/Safari

CSS d (SVG path) support in Firefox

The website gives more explanation of each feature and all of the details of how the funding will work. Igalia are working with Open Collective to manage the pledges.

Who Are Igalia?

Will Browsers Accept These Features If We Fund Them?

Why Don’t Browsers Just Do This Stuff?

I asked Brian why the browser companies don’t fund these things themselves. He explained,

How Does This Fit With Projects Such As Web We Want?

Get Involved!

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/crowdfunding-web-platform-features-with-open-prioritization/

0 notes

recruitmentdubai · 5 years ago

Text

First Steps into a Possible CSS Masonry Layout

It’s not at the level of demand as, say, container queries, but being able to make “masonry” layouts in CSS has been a big ask for CSS developers for a long time. Masonry being that kind of layout where unevenly-sized elements are layed out in ragged rows. Sorta like a typical brick wall turned sideways.

The layout alone is achievable in CSS alone already, but with one big caveat: the items aren’t arranged in rows, they are arranged in columns, which is often a deal-breaker for folks.

/* People usually don't want this */ 1 4 6 8 2 7 3 5 9

/* They want this *. 1 2 3 4 5 6 7 8 9

If you want that ragged row thing and horizontal source order, you’re in JavaScript territory. Until now, that is, as Firefox rolled this out under a feature flag in Firefox Nightly, as part of CSS grid.

Mats Palmgren:

An implementation of this proposal is now available in Firefox Nightly. It is disabled by default, so you need to load about:config and set the preference layout.css.grid-template-masonry-value.enabled to true to enable it (type “masonry” in the search box on that page and it will show you that pref).

Jen Simmons has created some demos already:

CodePen Embed Fallback

Is this really a grid?

A bit of pushback from Rachel Andrew…

Grid isn’t Masonry, because it’s a grid with strict rows and columns. If you take another look at the layout created by Masonry, we don’t have strict rows and columns. Typically we have defined rows, but the columns act more like a flex layout, or Multicol. The key difference between the layout you get with Multicol and a Masonry layout, is that in Multicol the items are displayed by column. Typically in a Masonry layout you want them displayed row-wise.

[…]

Speaking personally, I am not a huge fan of this being part of the Grid specification. It is certainly compelling at first glance, however I feel that this is a relatively specialist layout mode and actually isn’t a grid at all. It is more akin to flex layout than grid layout.

By placing this layout method into the Grid spec I worry that we then tie ourselves to needing to support the Masonry functionality with any other additions to Grid.

None of this is final yet, and there is active CSS Working Group discussion about it.

As Jen said:

This is an experimental implementation — being discussed as a possible CSS specification. It is NOT yet official, and likely will change. Do not write blog posts saying this is definitely a thing. It’s not a thing. Not yet. It’s an experiment. A prototype. If you have thoughts, chime in at the CSSWG.

Houdini?

Last time there was chatter about native masonry, it was mingled with idea that the CSS Layout API, as part of Houdini, could do this. That is a thing, as you can see by opening this demo (repo) in Chrome Canary.

I’m not totally up to speed on whether Houdini is intended to be a thing so that ideas like this can be prototyped in the browser and ultimately moved out of Houdini, or if the ideas should just stay in Houdini, or what.

The post First Steps into a Possible CSS Masonry Layout appeared first on CSS-Tricks.

source https://css-tricks.com/first-steps-into-a-possible-css-masonry-layout/

from WordPress https://ift.tt/2Zn8Xto via IFTTT

#web developer #web development #website developer

0 notes