- From: John A Bilicki III via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jul 2023 11:55:20 +0000
- To: public-css-archive@w3.org
@SebastianZ While the OP provided many examples they failed to comprehend the definition of which corner and direction do we start from. I corrected that by stating the top left moving in a to the right and then dowards motion like a clock (and not in conjunction with the progress element context). However their X/Y axis are otherwise presented in the correct 2D context. Their Z axis is presented in a Z axis context though you have to interpret is in a way since the image overall is only represented in a 2D context. >I believe, bending should work in a way so that the area an element has always stays the same. Now that is an interesting idea. However to have a meaningful conversation in that context there has to be an axiom about which corner the bend starts from which I have continued to suggest the top-left corner. With that presumption then a 180 degrees bend has the top-left corner stay in it's position and the top-right corner moves below it as in my my bendX(180deg) example posted on February 3rd. Then do we want the top-border that is now (visually) the outer/right to adhere to the width? What about the bottom border that is now smaller/inner in my visual illustration? >I believe, bending should work in a way so that the area an element has always stays the same. Wouldn't it be more affordable performance wise to calculate the total length of all four borders? If a height: 100px; width: 100px; has 400px of total border length then adjusting the borders to still have 400 pixels of border length seems like less work and then web designers could scale the element as/if needed. ---------- @dbaron >It would be interesting to have clearer explanations of what the underlying use cases are and what the visual effects that designers would really expect for those use cases are. An example that comes to mind: a 2D train animation. A vertical/2D train track in the middle of the page. As the user scrolls downwards a z-axis "bridge" would move upwards. While it was at the bottom (and if it had three dimensions) you'd see the "north"/"page's up" side. When the user scrolled to the point where the bridge was vertically center over the train track you'd see no sides and of course as you continued to scroll and the bridge appeared at the top you'd see the "south"/"page's down" side of that element. For food related websites think about rounded burgers, pies, pizzas, donuts, etc. It could be placed as a bottom-right quadrant in appearance at the top-left portion of the page as a visual part of a logo or menu. As a <menu> element each <li> element could appear as a "slice". Another example one could make a clock out of three elements that simply bend and then animate their rotation with each element having one of their borders be treated like a "hand" on a clock. Another example is being able to visually format text without having to resort to using shape-outside or using it in some kind of combination with it. Imagine bendZ() and then making the element twirl around via an animation showing different parts of the text. How about animating two elements relative to their surfaces? Imagine two pieces of paper in a three dimensional context. When at 0x0 one is completely over the other and then at 180deg the bottom one is now in front of the previously top element. At 90deg that top element would curve half over and half under the bottom element. There are some potentially serious implications for making websites themselves three dimensional in part or even whole. @tabatkins You've made it clear you fiercely believe that bend isn't a matrix transformation. We don't care that it is or isn't, we care that it gets defined, implemented and we are able to use it. So instead of fighting the idea because you don't believe it's a matrix then how about defining it with it's own parent CSS properties? A rough example: bend-axis: x|y|z; bend-origin: left|right, top|bottom; bend-degree: 180deg|100%; bend-context: area|border|content; The bend-axis should be a given. The bend-origin should define which corner the bending starts at. As I've suggested the top-left corner with bends moving in a top-to-bottom / left-to-right fashion by default however allowing people to change the "corner origin" would likely allow for different visuals especially in combinations of bends that we may not be considering right now. The bend-degree property should be fairly obvious as well. A 180deg should result in half a circle or be equivalent to 50% where as a 360deg or 100% bend-degree would result in the element becoming a circle. The bend-context would allow the area to be calculated in different contexts. Someone may need the element to bend while staying in "place". Someone else may need the element to "appear larger". I think there is more subjectivity in here and it's very much worth discussing different contexts of what would be considered useful. In example if the element is a paragraph without explicit height or width being defined the bend-context would default to content as obviously, paragraphs grow in size based on the amount of text (and/or descendant elements) that they contain. By moving the bend out of transform it removes the debate and would possibly make it easier to apply both transforms and bends to the same element with a less confusing set of syntax for web designers/developers. I'm not sure if I covered everything brought up here though the goal is to get past conflict and get this proposal past the initial conceptual stages because at the end of the day as web designers and developers we either have what we need to get the job done or we don't. -- GitHub Notification of comment by jabcreations Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6293#issuecomment-1634112213 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 July 2023 11:55:22 UTC