[HN Gopher] Things CSS could still use heading into 2023
___________________________________________________________________
Things CSS could still use heading into 2023
Author : corentin88
Score : 125 points
Date : 2022-12-23 11:33 UTC (1 days ago)
(HTM) web link (chriscoyier.net)
(TXT) w3m dump (chriscoyier.net)
| irrational wrote:
| I want all of the good features of jquery baked into native
| css/JavaScript.
| beardyw wrote:
| Fix styling on input range. Please.
| namuol wrote:
| At this point I'm pretty sure we'll have AGI and commercial
| fusion power before we get Mixins in CSS.
|
| Edit: I'm very happy with the last decade of progress in CSS at
| the feature level, but at the language level I get the sense that
| there's a fundamental disconnect with web developers.
| di4na wrote:
| This. Tbf i think this is a generic problem in the frontend
| tooling side.
|
| The build tools documentation and DX all seems built with the
| idea your html come from js or as static assets too. When in
| reality it is probably handled by a server side framework like
| Laravel, Django, Rails, Phoenix, etc
|
| I stopped having hopes on mixins. Now i just try to make a
| product successful enough that i can fund someone or a team to
| work on the problem in a decade. It feels like the most
| probable solution.
|
| And that is not a high probability of success...
| janitor61 wrote:
| font-size: [fit-width|fit-height|fit-container]; would be nice
| baggy_trough wrote:
| So many hacky font size adjustments over the years to keep some
| text from wrapping...
| willio58 wrote:
| Flowable regions would be amazing. Text placement edge cases
| would be mostly solved by this
| prox wrote:
| It's kind of amazing that we are going into 2023 and this isn't
| a thing yet. We need it yesterday!
| tannhaeuser wrote:
| The question is not what to add, but what to take away. But I
| guess this notion due to Antoine de Saint-Exupery is lost on CSS
| heads which brings us into the territory of another quote
| attributed to Upton Sinclair: "it's difficult to get a man to
| understand something, when his salary depends upon his not
| understanding it."
|
| By whom however I don't mean Chris Coyler even though his css-
| tricks.com when he was still running it certainly profited off
| CSS' let's say less-than-razor-sharp scope.
| christophilus wrote:
| Taking anything away breaks backwards compatibility, so that's
| a problem. I agree, though, that this means we should be really
| hesitant to keep piling on features.
| sergiomattei wrote:
| It's different with CSS. It's been so unreasonable and
| unergonomic for so many years, and for no reason whatsoever.
|
| Today I'm using PostCSS to get over these problems, but I
| wish I didn't have to.
| Joeri wrote:
| I feel like wasm is the way out of that. Keep the legacy
| standards but move them to an open source wasm implementation
| that's shared by all the browsers. This way making a new
| browser could be done without dealing with the mass of legacy
| and we might see the chromium monoculture broken.
| SirHound wrote:
| WASM comes with no standard library which is bad enough for
| replacing JS but a killer for CSS.
| pjmlp wrote:
| Dream on, WASM still hasn't a solid story for a GC after
| all these years, multi-threading isn't a given across all
| workloads, any new browser that doesn't run existing Web is
| worthless for the majority of consumers.
|
| Everyone that helped Chrome and Electron apps to be
| widespread, don't have anyone but themselves to thank for.
| samwillis wrote:
| That's literally the opposite of what WASM is good for.
|
| The browser platform is incredible because it doesn't break
| backward comparability, and has a very wide set of features
| to allow you to do 90% of what you want, but at an
| (occasional) cost of performance for the 1% of cases. WASM
| is there for that 1%.
|
| Figma is a good example, JS+SVG+Canvas+DOM would be too
| slow for their use case so they built a WASM renderer. But
| that renderer is limited in functionality to exactly what
| they need, that is where they gain there performance
| improvement. Not by being able to magically solve problems
| the browser devs haven't been able to. It just a case of
| having a simpler renderer.
|
| That's where WASM shines (for rendering), allowing you to
| simplify to gain speed improvements.
|
| It's exactly the same with using JS+Canvas for performance
| critical drawing where the DOM is too slow. Use a simpler
| toolkit.
|
| Running a whole browser in WASM will always be slower, and
| doing what you suggest would just result in a single
| implementation "monoculture" anyway.
|
| (On the monoculture comment, there isn't one, Safari is
| massive because of Apples block of other engines on iOS.
| Loose that block then there may well be a monoculture)
| holoduke wrote:
| I would like to have sticky elements on non parents. Very handy
| when you want to replicate android tab and header collapse
| functionality. Currently only possible with scroll listeners who
| are too slow and always show slight hickups.
| throwaway743 wrote:
| Text wrapping for SVG text without having to use foreignObject
| plusminusplus wrote:
| Nesting (like the `&` parent in Sass) is mentioned, for now there
| _is_ a PostCSS plugin for it.
|
| https://github.com/postcss/postcss-nested
| aliqot wrote:
| I just want a responsive textarea instead of counting columns.
| andrei_says_ wrote:
| Max-width: 100%; ought to work on text areas.
| azangru wrote:
| Dear Santa,
|
| I would like to have CSS units of viewport size that
| automatically subtract the scrollbar width. A cross between 100%
| (which discounts scrollbars but is unaware of viewport) and 100vw
| (which is aware of the viewport but does not exclude scrollbars).
| I understand that such a unit of measurement means overcoming
| infinite loops caused by edge cases. This is where your elves
| come in.
| Someone1234 wrote:
| On the face of it, the only thing I'd worry about is if
| scrollbars appear/disappear, and if that would cause the
| elements using this new unit to get resized up/down.
|
| Or to phase another way: If the scrollbar isn't currently
| rendered, is a hypothetical scrollbar still excluded or not?
| Since both ways you answer this question may make people
| unhappy.
| azangru wrote:
| The most common problem that I see is that people (almost
| always writing their CSS on a Mac, because Macs, by default,
| would hide the consequences of this) assign a width of 100vw
| to their header, footer, or main section, as a result of
| which, the moment that the page content's height exceeds the
| viewport height, the page will show not just a vertical
| scrollbar, but a horizontal scrollbar as well, because now
| 100vw is greater than 100% of body width.
|
| The above is easily fixed; however, I have also seen designs
| like this one [0], where a team has painted itself into a
| corner by assigning max-width to the body element; yet also
| wanting to have hero elements inside of the body element that
| would break out of the confines of the body and span the
| whole width of the viewport. They tried to use 100vw for the
| hero, which resulted in the infamous horizontal scrollbar.
|
| (I have since learnt -- from Josh Comeau, I think -- that
| their design problem could have been cleanly solved by
| designing the layout with CSS grid)
|
| [0] - https://i.imgur.com/LNyJIAq.png
| madeofpalk wrote:
| Do the new large/small/dynamic viewport units satisfy that
| need? https://css-tricks.com/the-large-small-and-dynamic-
| viewports...
| azangru wrote:
| No, they address ui elements other than the scrollbars.
| alberth wrote:
| I don't think that's correct. I think VMIN solves the OP
| comment.
|
| "Unit vmin refers to the smallest dimension of the
| viewport. Just like is the case with unit vw, unit vmin
| needs recalculation to _subtract the scrollbar_ from the
| viewport width.
|
| https://www.terluinwebdesign.nl/en/css/incoming-20-new-
| css-v...
| azangru wrote:
| From the article on the new viewport units, from the
| web.dev site maintained by Google[0]:
|
| "Caveats
|
| There's a few caveats to know about Viewport Units:
|
| - None of the viewport units take the size of scrollbars
| into account. On systems that have classic scrollbars
| enabled, an element sized to 100vw will therefore be a
| little bit too wide. This is as per specification."
|
| Notice that although the example in the above paragraph
| uses the well-known vw unit, the text explicitly says
| "none of the viewport units".
|
| [0] - https://web.dev/viewport-units/#caveats
| alberth wrote:
| scrollbar-gutter: stable
|
| Seems like someone else in this thread might have solved this
| problem.
|
| https://news.ycombinator.com/item?id=34116719
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...
| [deleted]
| chrismorgan wrote:
| > _means overcoming infinite loops caused by edge cases_
|
| It doesn't, really, if you instead just _commit_ to reserving
| space for the scrollbars. And this indeed was how viewport
| units were initially specified a decade ago, _and implemented
| in Firefox_ : write `html { overflow-y: scroll }` or similar,
| and vw is now actually what 100% of users want (seriously,
| there are _exactly zero_ valid use cases for the current
| behaviour, it's wrong _every single time_ --just very
| occasionally useful despite its unknowable-in-pure-CSS rate of
| error). Unfortunately, no one else implemented it or was
| interested in doing so (even though this was the only hope of
| making viewport units _correct_ for >99% of web pages--and
| remember this was before flex, too, so it was much more common
| to _need_ correct viewport units) and they ended up ripping it
| out of the spec and Firefox a few years later.
|
| And it looks like the only hope of ever getting sane viewport
| units is doing much the same once again, but more likely just
| with scrollbar-gutter this time. But having monitored relevant
| issues on the CSSWG bug tracker for years, I'm not holding my
| breath for any sort of fix. No, it's pretty clear that no
| browser makers are much interested in fixing ancient design
| bugs in scroll bars that take space.
| blowski wrote:
| Assuming browser developers are not insane or incompetent
| psychopaths, why do you think they've done it this way?
| c-smile wrote:
| > automatically subtract the scrollbar width
|
| Santa: "That is simply impossible with the default scrollbar
| model".
|
| You may have infinite loop in layout algorithm in cases when
| content is close to size of the viewport.
|
| 0) remove scrollbars
|
| 1) calculate VW;
|
| 2) do content layout;
|
| 3) if content exceeds viewport height, add v-scrollbar and goto
| 1 if it has not the scrollbar before;
|
| 4) if content does not exceed viewport height, remove
| v-scrollbar and goto 1 if it has it before;
|
| The only option is to use scrollbars that do not take space:
| normally scrollbar appears as thin semitransparent bar _on top_
| of content. And on mouse hover the real scrollbar appears , but
| again _on top_ of content.
|
| Such scrollbars do not cause re-layout as you see and VW is a
| viewport width always.
|
| That's why in Sciter(https://sciter.com) I've added
| overflow:scroll-indicator;
|
| That's exactly that non-taking-space-scrollbar.
| azangru wrote:
| Dear Santa,
|
| Please consult the list of gifts you brought to us for
| Christmas before the last. You will find included in that
| list the scrollbar-gutter property. With scrollbar-gutter set
| to stable, you could safely skip steps 3 and 4 in your
| algorithm, thus avoiding the infinite loop. Would you please
| consider giving our wish a second thought?
| c-smile wrote:
| Why do you need to waste screen space for the gutter?
|
| Check your mobile devices that use such scroll indicators.
| We haven't heard any major complaints about them.
| alberth wrote:
| calc(100vw - (100vw - 100%))
|
| Does above not work?
|
| https://stackoverflow.com/questions/33606565/is-it-possible-...
| chrismorgan wrote:
| No:
|
| (a) it only works on elements whose parents are the full
| viewport width, such as the body (simplifying the rules a
| little--there's much finer nuance to the interpretation of
| percentages), and most of the places you might want viewport
| units aren't suitable; and
|
| (b) that's literally just a longwinded way of writing "100%",
| because mathematics.
| anamexis wrote:
| As a comment on that answer points out,
|
| 100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%
| chrismorgan wrote:
| > _You can make anything resizeable so long as it's not an inline
| element and it has overflow: hidden;._
|
| Correction on the last part: so long as it's not `overflow:
| visible`. Doesn't need to be `overflow: hidden`, and indeed my
| experience is that you normally want `overflow: auto` on
| resizeable things.
|
| Also "anything" is inaccurate: you mostly can't use it with
| replaced elements like img/audio/video/iframe, though it varies
| by browser (e.g. my recollection is that resize works on iframe
| in Blink but not Gecko).
| Waterluvian wrote:
| I just want a reasonable way to show scroll bars without
| completely shifting the layout.
|
| Is there a way to reserve the scroll bar space but only show it
| on auto?
| azangru wrote:
| Of course. scrollbar-gutter: stable.
| dceddia wrote:
| Cool! I was hoping it was one of those hidden gems that's
| been there all along, but unfortunately doesn't work in
| Safari.
|
| https://caniuse.com/mdn-css_properties_scrollbar-gutter
| azangru wrote:
| It's in the standard, so it'll come.
| Waterluvian wrote:
| Well there's my unexpected Christmas gift for the year.
| Thanks!
| unvs wrote:
| I just want either a zoom constant so we can know how much the
| browser is zoomed in or out, or a scaling type size unit that
| will take zoom into account. In the former case we could set font
| size as vw multiplied with the zoom factor.
| Someone1234 wrote:
| > I just want either a zoom constant so we can know how much
| the browser is zoomed in or out
|
| So that zooming in on websites has unexpected side effects like
| some elements ignoring the zoom and staying the same size?
|
| When users zoom they want everything to maintain the same
| proportions but be larger on their display, but web developers
| in their infinite wisdom want to do clever stuff when a user
| zooms so that isn't their experience.
|
| What is a non-abusive use case for this?
| unvs wrote:
| Actually being able to zoom in font size when vw or vh is
| used. So it's to help maintaining what the user wants while
| being able to scale font sizes with viewport size.
| di4na wrote:
| Oh thank you so much for putting the mixins in this.
|
| It would be the most massive DX positive change to CSS. It had
| been on my want list for years.
|
| But it seems all the momentum went into shadow DOM and we stopped
| talking about it.
|
| "All" we need in theory is someone willing to take the mantle and
| shepherd it. There is previous work on it from the `@apply`
| experiment that could be leveraged. In theory it should not be
| _too_ hard.
|
| But noone has the time in the people that want it it seems.
| c-smile wrote:
| Just in case Sciter supports mixins out of the box.
| @mixin button-alike { border:1px solid;
| border-radius; background:gold; }
|
| and its usage a.button { @button-
| alike; // mixin application point color:blue; }
|
| Parametric mixins are also supported: @mixin
| button-alike(back) { border:1px solid;
| border-radius; background:back; }
|
| and a.button { @button-alike(gold);
| // mixin application point with parameter color:blue;
| }
| di4na wrote:
| Lot of stuff support it, but this is not really the same DX
| as... Just supporting it in browsers. Especially for
| debugging
| c-smile wrote:
| > Lot of stuff support it,
|
| @mixins are built-in in Sciter and I don't know any other
| HTML/CSS UA that supports that.
| di4na wrote:
| Tailwind has `@apply` from postcss
| pbowyer wrote:
| I can't wait for browsers to support
| https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim.
| It's been 4 years since it was introduced into the spec and
| there's been little movement. Maybe 2023 will bring it to Chrome?
| jacobp100 wrote:
| That spec isn't a candidate recommendation yet - so it's only a
| draft spec
| pbowyer wrote:
| Oh drat, thanks for pointing that out.
| geewee wrote:
| I'd settle for being able to style native selects properly
| leg100 wrote:
| What's the issue with bog standard selects? Is it purely
| aesthetics, or are there accessibility problems?
| Someone1234 wrote:
| Accessibility wise the default select/option is fine, because
| it does so little it is easy to reason about.
|
| Calling the problem "aesthetics" though is too narrow. There
| are numerous things people would like to see in a native
| select:
|
| - Optional search/filtering of options (without the need for
| an input field and JavaScript wiring).
|
| - Being able to style.
|
| - HTML in an option for example multi-line options.
| varun_ch wrote:
| Soon(tm)
|
| https://open-ui.org/prototypes/selectmenu
| CM30 wrote:
| Still surprised (and disappointed) how limited the styling
| options for native form fields are in CSS. Select fields,
| checkboxes, radio buttons, sliders and calendar inputs should
| be just as easily stylable as plain old text boxes and buttons.
|
| The fact they're not is probably hurting accessibility and
| usability a ton, since just about every individual and business
| wanting stylistic consistency is stuck reinventing the wheel
| with 'fake' versions or JavaScript.
| rhn_mk1 wrote:
| As an individual wanting stylistic consistency, I'd like for
| websites to leave my locally selected style the hell alone.
| mhuffman wrote:
| But alas, highly paid graphic designers that are hired by
| executives do not like your locally selected style and
| insist that it does not fit with their "corporate
| branding".
| Tagbert wrote:
| CSS Relativity?
| 11235813213455 wrote:
| <option> allowing html so?
| recrof wrote:
| dropdown menus are not stylable, that's the main problem.
| geewee wrote:
| I'm not exactly sure what you mean?
| kyriakos wrote:
| <option> element doesn't allow styled HTML content as a
| dropdown option. This has led into hundreds of non native /
| js based Select Dropdown implementations to overcome this.
| Not a bad thing but at the same time native controls are
| always better and gurranteed to work everywhere especially
| on mobile.
| c-smile wrote:
| Again, just in case...
|
| In Sciter, all input elements are ordinary styleable primitive
| DOM elements. <select> is there too so you can style it in the
| way you want: select {...} select >
| caption {...} select > button {...} select >
| popup {...} select > popup > option {...}
|
| Such composition goes even further. <option>s, for example, may
| have arbitrary content as also you can apply built-in DOM
| element controllers to DOM structure of your choice.
|
| This for example is a table that behaves as a <select
| type="list"> with rows-options: <table>
| <tbody style="behavior:select-list; overflow-y:auto;">
| <tr role="option" value="A"><td><td></tr> <tr
| role="option" value="B"><td><td></tr> </tbody>
| </table>
| danShumway wrote:
| > Flowable Regions
|
| Yes, yes, yes.
|
| I actually didn't love Adobe's standard, and I thought some of
| the criticism of it was warranted. But the overall feature would
| be very nice to have. I'm just not sure exactly how it should be
| approached. ----
|
| If I can be greedy, I know these aren't necessarily great
| features to add, but I would love:
|
| - an (optionally) less performant text-justification algorithm:
| Justified text on the web is basically unusable today, I think
| because of performance concerns with reflowing containers. There
| are scenarios though where I would be very willing to pay a
| performance penalty to get nicely justified text, even if I had
| to like mark a container in CSS as unable to resize/reflow or
| something.
|
| - CSS vertex shaders/custom filters: This is never going to
| happen as far as I can tell because of privacy concerns, and I
| have no idea how to get around those privacy concerns, and it's a
| feature I would almost certainly turn off in my own browser for
| most websites, but... I still want them.
|
| ----
|
| Also I'm hoping that 2023 is potentially the year where I can
| start to feel safer about using container queries:
| https://caniuse.com/css-container-queries. I think once they hit
| mainline Firefox, Chrome/Safari/Firefox will be good enough
| support that I'll be comfortable including them at least in niche
| projects and just using progressive enhancement and a slightly
| uglier style as a fallback for other browsers.
| eternityforest wrote:
| I still really want native squircle borders.
| wbobeirne wrote:
| Clip-path gives you all the flexibility you could want,
| although not as convenient.
| webstrand wrote:
| `clip-path: path(...)` not having relative units makes it
| basically useless for non-fixed size elements. And embedding
| an SVG into your html with a `<clipPath>` declaration is
| fragile and hackish.
| Waterluvian wrote:
| I thought it was all about the round rect!
|
| https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
| chrismorgan wrote:
| Rounded rectangles are easy to manufacture, but ugly due to
| their tangency. For best results, you want to smooth the
| curvature--whether in the form of squircles, or something a
| bit more locally-constrained.
| https://99percentinvisible.org/article/circling-square-
| desig... shows the difference nicely if you (or any other
| reader) are unfamiliar with it.
| samwillis wrote:
| This so much! I'm surprised that Apple haven't implemented it
| in Safari so they can use them to match their style elsewhere.
|
| I'm not sure what the spec should be though, maybe bezier curve
| corners. That would allow asymmetry with "setback" and
| "control-length" for each side of the corner.
| mintaka5 wrote:
| [flagged]
| asddubs wrote:
| position:device-fixed;!
|
| https://www.quirksmode.org/blog/archives/2010/12/the_fifth_p...
|
| Basically a version of position:fixed that doesn't get zoomed in
| on when zooming the rest of the page on mobile, so it's always
| actually visible. would be hugely useful for making bottom/top
| menus like apps have, without having to re-implement zooming in
| javascript.
| SigmundA wrote:
| Full print/paged media support so Prince XML is no longer needed.
| [deleted]
| CM30 wrote:
| There are definitely some good examples here. The fact that this:
|
| > Animate to Auto
|
| Still isn't possible with vanilla CSS in 2022 just boggles the
| mind, especially given jQuery managed to get it working decades
| earlier.
|
| Similarly, why can't we have different visible and scroll/auto
| values for overflow? Like, this feels like the weirdest
| limitation to be stuck with decades later:
|
| > The computed values of 'overflow-x' and 'overflow-y' are the
| same as their specified values, except that some combinations
| with 'visible' are not possible: if one is specified as 'visible'
| and the other is 'scroll' or 'auto', then 'visible' is set to
| 'auto'. The computed value of 'overflow' is equal to the computed
| value of 'overflow-x' if 'overflow-y' is the same; otherwise it
| is the pair of computed values of 'overflow-x' and 'overflow-y'.
|
| Such utterly bizarre design choices that don't take
| designer/developer expectations into account at all.
| chearon wrote:
| The browser doesn't know what the auto size is any more than
| you do until it performs a layout (reflow). Layouts are
| expensive and must be minimized. And what if content is changed
| in the middle of the transition? Should it recalculate the new
| auto size? Maybe we will get it some day, but there are good
| reasons to be cautious.
|
| I'd go as far as saying layout properties like `height` and
| `font-size` shouldn't even be animated. If you pay attention to
| animations on macOS or iOS, the animations are performed on
| post-layout pixels: scaling and translating. That gets you very
| smooth FPS and isn't thrashing the CPU.
| kyleyeats wrote:
| Love this comment. In general I think developers shouldn't
| change the height of things, animation or no. If you're using
| _vh_ then the page shouldn 't have a scrollbar at all. You
| should only ever use it to fit your whole UI on one screen.
|
| I actually can't imagine any other use for _vh_ that isn 't
| related to screenjacking (giving you a "full screen
| experience" mid-article) or scrolljacking (changing how the
| page scrolls). Parallax effects, maybe? I like the current
| limitations.
| reflectiv wrote:
| > I actually can't imagine any other use for vh that isn't
| related to screenjacking
|
| Creating fixed panels on the left or right side of the
| viewport that are full height and sticky.
| mpawelski wrote:
| But it's clearly the feature that people want and expect to
| be there. This is the most upvoted issue on CSS WG Github[0]
| and the StackOverflow question how to do it in CSS has 3
| pages of answers (spoiler-alert: there is no nice way to do
| it only with CSS).
|
| > The browser doesn't know what the auto size is any more
| than you do until it performs a layout (reflow). Layouts are
| expensive and must be minimized. And what if content is
| changed in the middle of the transition? Should it
| recalculate the new auto size? Maybe we will get it some day,
| but there are good reasons to be cautious.
|
| Unfortunately these are good questions to answer and probably
| the reason browsers don't have it yet.
|
| Last time I had to animate `width:auto` and `height:auto` I
| came up with quite a clever idea. I wrote `width:
| var(--width-from-js, auto)` and `height: var(--height-from-
| js, auto)` (CSS Variables (called CSS Custom Property[2])
| with a fallback to `auto` when the variable is not defined)
| and later in JS I calculated the real width and height (using
| `getComputedStyle` or `getBoundingClientRect`) and just set
| `--width-from-js` and `--height-from-js` as inline style on
| the element. I also added event handler for the event that
| could change the size of this element (like browser window
| resize) and rerun this code to set updated CSS Property
| valaues.
|
| This way the changes required in JS were minimal, most of the
| things was in CSS. As a plus when one day browser would
| support animation to `auto` I would only have to delete the
| JS code.
|
| I need to write about this technique on this 3-pages
| stackoverflow question one day ;)
|
| Interesting observation was that when there was an animation
| in progress and the code for calculating the width of the
| element had run (because I resized the browser window) then
| the animation would just stop. I wouldn't mind if this was
| also the behavior if browsers would someday support animation
| of `width/height: auto` natively.
|
| [0]https://github.com/w3c/csswg-drafts/issues/626
| [1]https://stackoverflow.com/questions/3508605/how-can-i-
| transi... [2]https://developer.mozilla.org/en-
| US/docs/Web/CSS/Using_CSS_c...
| c-smile wrote:
| > Animate to Auto
|
| Sciter supports animate to min/max-content. This
| div { height:0; overflow-y:hidden;
| transition: height ease 300ms; }
| button:checked + div { height:min-content; }
|
| will animate the following:
| <button|checkbox checked>Show/hide</button> <div>
| This is a summary </div>
|
| so technically that's possible. And browsers are in principle
| capable of doing that too if they support animation in
| <summary>/<details>
| agolio wrote:
| > Ya know how a <textarea> is resizeable by default?
|
| Ah, yes, I knew that.
|
| (mind silently blown)
| c-smile wrote:
| resizable <textarea> is generally quite a limited thing.
|
| It would be significantly more useful if we would have
| universal <frameset>: <frameset cols="200px,*>
| <select type="list">...</select>
| <textarea>...</textarea> </frameset>
|
| so to have split views.
|
| Resizable textareas are quite trivial to implement with
| barebone JS but such split views require native support from
| browsers in order resizing to work effectively.
| dangoor wrote:
| Am I the only person seeing JSON when I follow this link?
| jwilk wrote:
| https://archive.today/2GhX3 may work better.
| maxloh wrote:
| Me too.
___________________________________________________________________
(page generated 2022-12-24 23:00 UTC)