[HN Gopher] CSS Container Queries in Web Components
___________________________________________________________________
CSS Container Queries in Web Components
Author : mxbck
Score : 90 points
Date : 2021-05-16 11:47 UTC (11 hours ago)
(HTM) web link (mxb.dev)
(TXT) w3m dump (mxb.dev)
| slver wrote:
| I tried to read through this I couldn't figure out what problem
| was solved. Does anyone have TLDR?
| jimmont wrote:
| I found these an easier read https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_Contain...
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...
| btown wrote:
| Does anyone know if React will be able to interop with this?
| Certainly there are solutions to letting a React component re-
| render based on its own width, even as that might change over
| time. But I imagine there would be performance improvements to
| let CSS container queries handle all styling for a component,
| rather than needing to go back into JS land every time. And
| because said CSS would be scoped, it would make CSS-in-JS
| possible without needing to add auto-generated prefixes etc.
| You'd perhaps need your React component (not each component
| instance) to maintain a template for itself, which might be
| tricky.
| eyelidlessness wrote:
| If I remember correctly, React web component support is
| limited. But Preact explicitly supports them, as well as many
| other JSX libraries.
| muspimerol wrote:
| Why would you want React interop for the styling? What would
| that even mean? Struggling to understand the use case here.
| jopsen wrote:
| I keep having mixed feelings about web components...
|
| Why can't we have templates, custom elements and scoped CSS
| without JS?
| qbasic_forever wrote:
| There's no generic HTML import function yet. Right now you can
| only have a page pull in javascript (through a script tag or ES
| module import) or CSS files, but critically not component HTML
| files. So it's hard to have a component defined by HTML and CSS
| that can be shared and imported in other pages. There's no
| "grab this HTML page and give me the DOM to insert/clone/use
| how I please" in pure HTML. The closest thing is iframe but
| it's not really a general component tool. For better or worse
| JS is currently the way to share logic and fragments between
| HTML pages. There was a working group looking at HTML imports
| but I think it all got spun down.
| e111077 wrote:
| HTML Imports did exist and was the general authoring idea for
| web components, but it didn't work exactly as you described
| and Apple and Mozilla shut it down. Polymer had to release a
| new version that was JS focused and caused a huge painful
| migration for users.
| jrochkind1 wrote:
| I am not very familiar with the technology. Under current
| standards, is it possible to choose to write a web component
| that does not have any JS, it just uses CSS to take advantage
| of these things?
| qbasic_forever wrote:
| No, a web component by definition must be a class that
| inherits from a HTMLElement base class and implement some
| basic rendering functions. In addition you must make the
| browser aware of the component by calling a
| CustomElementRegistry.define function with your class and the
| desired component name. So at a minimum there's about 5-10
| lines of boilerplate JS necessary to define and register a
| basic component.
| e111077 wrote:
| You described a Custom Element a Web Component is a
| branding phrase for component that uses the four following
| specs:
|
| * Custom Elements
|
| * Shadow DOM (seems to be optional in practice)
|
| * HTML Template Elements
|
| * ES Modules (formerly HTML Imports)
| runarberg wrote:
| If I remember correctly some WHATWG members are trying to
| settle on a syntax for declarative shadow DOM[1]. I personally
| wouldn't hold my breath for it though, I don't know how
| enthusiastic the rest of WHATWG is about this.
|
| In the meantime I would look for technology which applies
| server side rendering to your web components.
|
| 1: https://web.dev/declarative-shadow-dom/
| jimmont wrote:
| Why server side rendering? Content that needs rendering just
| put in the tree and target a slot. My perception was this is
| the best practice. I haven't used the lit included intl
| translation and am curious if and how these concerns work.
| runarberg wrote:
| Doesn't that still require JavaScript?
|
| As I understand it (and I might not; I don't have servers
| to do SSR) people want SSR for two reasons. a) To allow
| users that don't have JavaScript for some reason to at get
| good UX, and b) to prevent the styles from kicking in after
| the initial render. There are ways to author your
| components in a way that fixes (b), but I'm not aware of
| any technique other then SSR that will fix (a).
| e111077 wrote:
| I don't think anyone is really targeting JS-less users.
| It's mostly for faster first renders and the examples of
| JS-less is to typically show something has been SSR'd and
| not yet hydrated / not loading anything that isn't needed
| for first render.
| eyelidlessness wrote:
| > I personally wouldn't hold my breath for it though, I don't
| know how enthusiastic the rest of WHATWG is about this.
|
| DSD is already shipping in Chrome 90 and Edge 91. I suspect
| that will put pressure on others to either adopt or continue
| with the standardization process until it addresses their
| outstanding concerns.
| [deleted]
| incrudible wrote:
| https://en.wikipedia.org/wiki/Inner-platform_effect
| jimmont wrote:
| that's arguable, the encapsulation web components affords is
| built into the system and simply being exposed by way of this
| bucket of technologies
|
| When compared with React and similar solutions doing the same
| and similar thing(s) it runs circles around them... or am I
| misunderstanding the comment and is the position asserted
| that container queries (not web components) are the effect?
|
| What is the inner-platform effect comment applied to
| specifically?
| incrudible wrote:
| > What is the inner-platform effect comment applied to
| specifically?
|
| Adding more flexibility to CSS/HTML _without_ requiring
| Javascript would eventually turn CSS and HTML into to the
| equivalent of a general purpose programming language, which
| we _already have_ in the form of Javascript.
| ______- wrote:
| > Each of these books is a custom element, or "web component".
|
| I always wondered about custom 'web components'. Is it safe to do
| something like this? --> <style>
| red{color:red} </style> <red>I should
| be red</red>
|
| It works in latest Firefox. It feels weird being able to create
| arbitrary custom elements like that!
| runarberg wrote:
| Short answer: No. There is no guarantee that a future HTML spec
| will include a standard element <red> which will affect yours.
| For your element to be a legal custom element it must include a
| hyphen (e.g. <my-red>).
|
| Longer answer: What you did here is a simple CSS selector using
| a tag matcher. Each tag with the name "red" will be matched and
| styles applied. If you want some custom script applied when
| this kind of element is created, attached, destroyed, etc. you
| must create a class for it and register it to the custom
| element registry[1]:
| window.customElements.define( "my-red",
| class extends HTMLElement { // ... },
| )
|
| Now you have a custom element. But when people normally speak
| of _web components_ they are talking about scoped elements,
| which means styles and idrefs are encapsulated. For that you
| must attach a shadow DOM[2] to your element:
| class MyRed extends HTMLElement { constructor() {
| super(); const shadowRoot =
| this.attachShadow(); const style =
| document.createElement("style"); const slot =
| document.createElement("slot");
| style.textContent = ":host { color: red; }"
| shadowRoot.append(style, slot); } }
|
| 1: https://developer.mozilla.org/en-
| US/docs/Web/API/CustomEleme...
|
| 2: https://developer.mozilla.org/en-
| US/docs/Web/API/Element/att...
| ______- wrote:
| Thanks for clarifying
| dqv wrote:
| IIRC that's a Firefox quirk and doesn't work in every browser.
| ______- wrote:
| Do you know what the quirk is called? Is there a blogpost
| detailing this strange method? Is there any mention of it in
| the web standards sites?
| lolinder wrote:
| I don't believe it's a quirk. Browsers are supposed treat
| tags they don't recognize basically the same as a <div> (or
| some other reasonable default presentation). It's
| intentionally designed that way for forward compatibility.
| We rely on this behavior when we provide some content
| inside an <object> tag for browsers that don't support it.
| e111077 wrote:
| HTMLUnknownElement
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/HTMLUnknown...
| [deleted]
| shakna wrote:
| Yes, that is safe. It was introduced in 2014. I believe it
| should work in most browsers. (Rough testing shows it working
| for me in Firefox, Chrome, Safari).
| ______- wrote:
| Is there some page/article/reference to that method that you
| know of?
| shakna wrote:
| Custom Elements [0][1] is the specification that came after
| the implementation was already gaining use.
|
| [0] https://www.w3.org/TR/custom-elements/
|
| [1] https://html.spec.whatwg.org/multipage/scripting.html#c
| ustom...
| ______- wrote:
| Thank you!
| tuxie_ wrote:
| I've picked up css after ~5 years and I can't believe how far
| it's come. Flexbox, grid, `clamp()`, content queries, etc. It's a
| complete different experience now compared to the days of css
| hacks.
| FriedrichN wrote:
| Every time I hear someone complain about CSS I just know
| they've never used it in the IE6/7 days. Good lord, the amount
| of hacks, shims, fallbacks, polyfill, obscure stuff you had to
| do to make it work in IE6, IE7, and my absolute favourite(!)
| the IE7 compatibility mode which was like IE6 but not quite!
|
| Ever since the wide adoption of stuff like flexbox and grid I
| haven't dared to complain about not getting stuff to work.
| ehayes wrote:
| I've seen things you people wouldn't believe. Clearfix
| classes assigned to every element. I watched rounded
| rectangles built in Photoshop, sliced and exported to PNGs,
| then aligned with tables and a prayer. All those hacks will
| be lost in time, like tears in rain. Time to design.
| crispyambulance wrote:
| I remember the dumpster-fire days too.
|
| The thing that I can't understand is, why did it take SO LONG
| to get useable, proper, and intuitive CSS-based layout on
| web-pages?
|
| I mean, we've had all kinds of rock-solid mechanisms for
| layout in desktop applications since the dawn of GUI's in the
| NINETEEN EIGHTIES. Meanwhile, in CSS, people had resort to
| HTML tables up until sometime in the early naughts, when
| AWFUL, counterintuitive float-based hacks were part of the
| "Web 2.0" buzz.
|
| For Christ's sake, just getting fixed side-bars and a width-
| adaptive central area was called "The Holy Grail" by CSS
| experts. Isn't that the one of the most fundamental layouts
| GUI's-- AKA "The Docpanel"? It wasn't possible to get really
| nice layout without crazy hacks until flexbox in 2010-ish?
|
| Finally, a few years after flexbox, CSS grid comes out, and
| oopsie, we weren't supposed to use flexbox for overall layout
| anyway. Now it's CSS-grid for 2D (page layout), Flexbox for
| 1D (component layout), and floats for what they were
| originally intended for (putting pictures into a block of
| text and have the text flow around the pictures).
|
| To be fair, I actually like CSS now. It seems like it's
| really reached a point where you don't have to cling tightly
| to somebody's zany overcomplicated framework and can pretty
| much execute your will without frenetic trial and error.
|
| So NOW it's a success, but it's distressing that I feel CSS
| deserves nothing more than a sarcastic SLOW CLAP?
| dmitriid wrote:
| > The thing that I can't understand is, why did it take SO
| LONG to get useable, proper, and intuitive CSS-based layout
| on web-pages?
|
| Many reasons:
|
| - HTML and CSS are not designed for anything complex.
|
| HTML and CSS at their core are only meant to display a
| static page of text and some images in a single rendering
| pass on a computer from 1990s.
|
| - Many decisions in CSS (especially early CSS) are one-off
| solutions that might not even have correct specifications
| compared to how people usually use it
|
| Float is really a one-off solution for a very specific
| subset of layout. The standard box model famously has a
| default that no one in real world uses, and that IE
| actually got right. There are more:
| https://pavpanchekha.com/blog/css-problems.html and
| https://www.impressivewebs.com/css-the-bad-parts/
|
| - Any solution has to be aware of any previous solution and
| mistake
|
| Let's say, you introduce flex. How will it work with
| floats? What about display:inline or display:inline-block?
| Tables? Inside tables?
|
| Let's say you introduce grid. All the question above _plus_
| all the questions on how it will behave with flex.
|
| Let's say you introduce...
|
| - Standards are mostly driven by browser implementors, who
| are not known for any/much of web work. Additionally,
| solutions have to be "fully complete including edge cases
| that maybe one person in the world cares about".
|
| Cant' find the link for that, sorry, you'd have to take me
| at my word :)
|
| - All that still has to work reasonably fast for some
| definition of fast, _including_ all the weird interactions
| between mistakes and other workarounds of past, present,
| and future
|
| For example, Cassowary constraint solving algorithm for
| layouts was proposed in 1999, but was rejected because it
| was deemed too costly to process.
| crispyambulance wrote:
| > HTML and CSS are not designed for anything complex.
|
| Yeah, I believe you, I can see how that would have been
| the thinking back in the 90's. But there started to be
| significant web applications in the early 2000's.
|
| It's all water under the bridge now, but what if there
| had been more "throwing away" (deprecation) of the bad
| stuff and less mitigation with the whims of browser
| implementors? I feel like we would be in a better
| position today.
|
| What if the W3C had taken a more standards-based approach
| with hard PASS/FAIL requirements on
| styling/layout/semantics rather than "recommendations"
| that browser implementors have always taken as optional
| and subject to interpretation?
| ehayes wrote:
| Just to give the less grizzled devs among us an idea how much
| better things are today: 14-ish years ago we all wanted
| rounded corners, but there was no border-radius (or at least
| we couldn't use it because IE). So it seemed like the web was
| full of rounded corner tutorials, and all of them involved
| jumping through a bunch of hoops. This thread reminded me of
| this parody of rounded-corners called "How to Make Square
| Corners with CSS" containing their coveted 84 step process to
| beautiful square corners in CSS:
|
| http://web.archive.org/web/20071014004940/http://www.drivl.c.
| ..
| asddubs wrote:
| want a drop shadow on a div? no problem, just wrap it in 8
| other divs and give each of them a different background for
| the sides and corners
| orware wrote:
| I had been trying to get into Tailwind CSS in recent projects
| but noticed some of the Bootstrap functionality I tend to
| like was missing out of the box so with Bootstrap 5 coming
| out last week I switched gears to start using that for a new
| project.
|
| The project itself is an update to an older one that was
| originally built with Bootstrap 2.
|
| For the old one, when I go to print the somewhat detailed
| tables I'm using show up fine, but in the new Bootstrap 5
| version, one of the tables sticks outside of it's container
| when going to print and for the life of me I've been
| struggling to figure out a solution that works consistently
| for the print side of things (which I feel tends to be
| overlooked quite a bit in regards to CSS). What's even odder,
| is that when I implement a change that helps with the second
| table (making it appear contained within the page dimensions)
| the first table above starts exhibiting the issue of it being
| outside of the container. Also, in this case, if I were to
| leave the default styling of the "table-responsive" div
| containing the table, you wouldn't be able to see the rest of
| the columns at all when printing (since the scrollbar would
| show up) so everything I'm describing above is with an
| override to have "overflow-x: visible" when printing. Some
| other suggestions online included adding some overrides that
| use "page-break-inside: avoid;" for tables/tr/td/div elements
| and "display:block !important;" for the body and div elements
| but I'm not completely happy with those results, but yup
| that's been a bit frustrating trying to sort out since I'm
| not even sure why it's behaving the way it is at the moment.
|
| I haven't kept up fully with all of the Sass/SCSS
| advancements in recent years but have a semi-decent CSS
| foundation to build off of (from my understanding those
| advancements primarily help with some additional programmatic
| elements that then get pre-processed back into CSS? Along
| with some syntactic sugar to simplify some of the
| repetitiveness that CSS can require).
|
| The other big annoyance I was dealing with was related to
| what appears to be a long-standing WebKit issue related to
| scrollbars on mobile devices? (for the theme I'm using, I'd
| scroll down on an iOS device and wouldn't be able to see the
| very last item in the mobile menu). I found a reference
| somewhere (probably Stack Overflow of course) that mentioned
| using "@supports (-webkit-touch-callout: none)" to try and
| target the mobile browsers specifically and I reduced the
| height by an extra 65px or so which seemed to be enough to
| help with that particular issue (the theme utilizes "perfect
| scrollbar" it seems, but not entirely sure about all of the
| styles involved). (Before settling on this solution I had
| already tried out the solution described over here:
| https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-
| in-...).
|
| One last item I was dealing with this week seems to have to
| do with SVG rendering on the desktop vs. on mobile (for a
| logo). We sort of have a designer on staff but he deals more
| with print than with web stuff so I asked for a variation of
| our logo with the name of the application integrated into it
| and provided back to me as an SVG (since the PNG I had
| created myself looked slightly fuzzy when it was downscaled
| to fit the space I was using it in on the page, so I felt an
| SVG version would look crisper). After swapping things to the
| SVG version provided to me, it looks pretty good on mobile,
| but on the desktop (both in Chrome and Firefox), things just
| don't look as good. Some resources online mention it could be
| related to the lower DPI of a desktop monitor vs. the retina
| type DPI of a mobile device, but I don't know...I also saw
| some mention of a "pixel hinting" approach that might be able
| to be utilized by the designer in Adobe Illustrator perhaps
| that might help as well so that's something I've asked him to
| give a try for me so we can see the results, but I was kind
| of disappointed about the way the SVG looked as well (and now
| that'll require a bit of extra time to
| research/learn/experiment about, rather than focusing more on
| the application I'm trying to actually build...but at the
| same time it's semi worth it at the moment since I'm hoping
| the foundation I'm building with this new web app will be
| utilized in a couple of other updates that I'd like to make
| over the coming year, but we'll see how it goes ;-).
|
| I'll postscript this message that I'm not a frontend dev, but
| since I'm basically a team of one with an eye for certain
| details/issues, I try and get these sorts of problems sorted
| out at the beginning of a project so they don't cause issues,
| but also as a team of one, I really wish that in addition to
| the backend frameworks that are available (Laravel in my case
| is the one I'm currently ramping up on, as it's the more or
| less leader on the PHP side), it would be nice to have a nice
| frontend option with "batteries included" for a developer to
| really utilize and not have to worry too much about
| (Bootstrap has probably been the closest in that regard...I
| do like a lot of what Tailwind CSS is doing though, and of
| course it's heavily promoted in the Laravel community, but I
| just found that it would require too much work for me and too
| much time...and my workplace isn't exactly software
| development focused so I have to pick my battles in that
| regard vs. spending a lot of time getting something basic
| going vs. getting something shipped for users to start
| using).
|
| Hopefully one day we'll be completely away from needing to do
| any sort of CSS hacks (and things have come an extremely long
| way in the past few years), but at the moment I wouldn't say
| things are completely hack free yet (at least for us non-100%
| frontend folks...you all might have some extra magic you can
| cook up on the fly to solve any problems encountered maybe
| using what's already available :-).
| 0x10c0fe11ce wrote:
| I've been there. The truth is that css media print doesn't
| work with anything complex. After spending a week at it
| back in January, it felt very much like IE6 whac-a-mole.
| Long story short, I ended up fixing it in python using
| rst2pdf. Brilliant library.
| taf2 wrote:
| zoom:1;float:right;
|
| There it's fixed
| deanclatworthy wrote:
| Ah you young ones only supporting IE6. I still have trauma
| from supporting IE5!
| asddubs wrote:
| that's nothing, back in my day we had to manually carve the
| website layout into clay tablets
| username91 wrote:
| position:relative on everything if you wanted it to be
| visible. var undefined; Fun times.
| jozzy-james wrote:
| ie 5...mac edition :shudder:
| jraph wrote:
| My favorite obscure thing: you sometimes had to add the
| zoom:1 CSS declaration so the element would "have layout",
| Whatever that meant, so it behaved the way you wanted.
|
| You also had the various filter: progid:DX... declarations to
| make things that came with other browsers work on IE using
| DirectX directives. This would, by the way, break the CSS
| syntax because of the colon in the value, but fortunately
| parsers of other browsers would recover at the right place.
|
| You could also run arbitrary JS in this filter property, too.
| I don't know how this would have worked with CSPs today.
|
| To add to the confusion, the filter property has since been
| repurposed, and the modern one is NOT related to the older,
| IE one.
|
| One of the biggest issues at the time was the non-standard
| box model that IE used and there was no way to tell other
| browsers to use this box model, nor to tell IE to use the
| standard box model.
|
| Now both can be used in any browser with box-sizing:border-
| box (the IE box model) or box-sizing: content-box (the
| default standard box model). I guess browsers needed to
| implement border-box for the quirks mode anyway.
|
| Conveniently, IE would happily load specific stylesheets
| declared in "conditional comments" so it could be possible to
| fix some things. Or you could use weird syntax like prefixing
| property names by a star, that the IE CSS parser would not
| mind but the other browsers ignore. Each version of IE had
| its specific quirks in its CSS parser so it was possible to
| target one version or another. Which is fortunate, because
| the rendering engine behaved very differently from version to
| version.
| goldenkey wrote:
| The box-sizing property is actually very useful for when
| you want to reserve space in a percentage sized element
| with different sizing units.
|
| For example (in SASS CSS): .container {
| $footer-size: 2em; box-sizing: border-box;
| height: 100%; padding-bottom: $footer-size;
| .footer { position: absolute; bottom: 0
| left: 0; height: $footer-size; } }
|
| Otherwise, one would have to use calc() which isn't
| supported in older browsers.
| jraph wrote:
| Absolutely. By the way, it seems many frontend developers
| generally prefer box-sizing:border-box, and Bootstrap
| sets it for all elements by default.
|
| Which can be a little disturbing when you don't know it,
| work on a project that includes bootstrap and you expect
| content-box. Fortunately, browser dev tools are good at
| telling you what is going on.
| goldenkey wrote:
| Thanks, I wasn't aware of this disparity. I handwrite my
| CSS, been doing it for 21 years now.
|
| If I was to use Bootstrap or Tailwind, I'd likely use
| @extend and @include to compose my own classes.
|
| A long time ago, I read an article that stated, with
| authority, that Bootstrap was being misused. That class
| names like "font-weight-light mt-4 text-white" should
| instead have been replaced with "subtitle" with CSS:
| .subtitle { @extend .font-weight-light, .mt-4,
| .text-white }
|
| The article resonated with me. This approach avoids
| mixing HTML/CSS concerns and also avoids polluting the
| CSS namespace. Even if tree shaking and css pruning is
| applied, I believe this approach would win out in
| performance for having less classes. I would be wrong if
| there are tools that will run through HTML and CSS and
| transform the long bootstrap class attributes into
| consolidated, shared classes.
|
| Global classes, like in Bootstrap, also violate web
| component encapsulation.
|
| Global CSS classes are kind of like global variables in
| programming languages (like PHP.) Sure, they work and
| used to be common, but we've since moved on to closures
| and scope containment for performance and reliability.
| jraph wrote:
| I thought this when I first encountered Bootstrap, and it
| is still my opinion today. I think class names should
| convey intent and meaning, not the look. I'm glad someone
| wrote on this.
|
| People seem to like bootstrap, but it seems with
| bootstrap, not only you have to master CSS, but also
| bootstrap, while without it you only need to master CSS.
| I'm also used to hand write CSS and I'm a bit at loss
| when I need to use such CSS frameworks. It seems that
| some people find it easier to deal with CSS with
| Bootstrap (including people who don't really like CSS),
| but haven't really understood this to this day. I know
| the default behavior of a web page pretty well, but as
| soon as bootstrap is there, this knowledge is partly gone
| and my assumptions are broken. It just makes my life a
| bit harder.
|
| This would be fixed by learning Bootstrap properly but I
| just don't see the appeal, especially that I noticed
| defaults that I don't like (the sizing for headings for
| instance). It does not seem to solve a problem I have. It
| does provide interesting components like popovers though.
| jazzjazz wrote:
| There is a site called maintainable css that resonated
| with myself regarding CSS naming and approach.
| https://maintainablecss.com/
| bassdropvroom wrote:
| I used to be a full-stack developer 5 years ago, and while I
| wasn't an expert I was pretty good with front-end development.
|
| Recently I've started picking up a new side project, and I'm
| absolutely gobsmacked how far front-end development has gotten
| in just 5 years. It's a completely new landscape. It feels like
| I'm having to learn it all from scratch again.
| trinovantes wrote:
| I've been really impressed with the simplicity of
| display: flex gap: 10px
|
| No more having to deal with :first-() :last-() selectors to
| remove margins
| jozzy-james wrote:
| gap only applies to the inner contents tho - so still need to
| (potentially) handle outer margins. still, css grid is
| wonderful...just waiting for sub grids so i can do away with
| some hacky js height calculation i still need to do.
| trinovantes wrote:
| Yea, I should've clarified I meant not having to deal with
| margins for children elements. Thankfully with gap, I
| rarely have to worry about parent container's margins
| victor106 wrote:
| What are some good resources to learn modern css?
| asddubs wrote:
| kevin powell on youtube makes good videos, it's how i finally
| jumped into flexbox and grid a while back. I think for
| something like CSS videos really are a good medium for
| teaching
| qbasic_forever wrote:
| I really liked this zine by Julia Evans:
| https://jvns.ca/blog/2020/11/22/new-zine--hell-yes--css-/ It
| helped me get over the hump of realizing most modern CSS is a
| very simple and clear subset of all CSS. I.e. don't get
| bogged down in legacy or browser specific quirks and
| eccentricities--stick with modern conventions like flexbox,
| grid, etc.
| petepete wrote:
| I was explaining to a much younger colleague the hoops we used
| to have to jump through to get rounded corners and drop
| shadows. He honestly thought I was lying when I told him it
| involved exporting sliced-up images from Fireworks and placing
| them in tables.
|
| Now it's two lines of CSS.
| tuxie_ wrote:
| LOL fireworks! I had forgotten about that.
| inshadows wrote:
| Styling <table> still sucks though. I mean for displaying
| tables, not layout.
| ThatMedicIsASpy wrote:
| making tables a css grid is not an option?
| asddubs wrote:
| not if it's a really long table, grid fails at 1000ish rows
| in chrome
| jozzy-james wrote:
| tbf, if you have a 1000 row table in html - you might
| have other problems.
| asddubs wrote:
| agreed. To be fair in my case it was a 500+-row table
| that i was trying to split into 2 rows each on small
| screens. Still arguably way more than reasonable, but
| this was a situation where it's legacy code and I could
| only change the html/css. I ended up doing each row as
| it's own flex, which is slightly annoying since it can't
| adapt to the contents being displayed, and I had to just
| stipulate widths for each column, but I guess it's not
| hard to see why dynamically calculating the widths would
| be a bit laggy.
|
| Firefox handled arbitrarily big grids like a champ though
| jozzy-james wrote:
| > not layout
|
| email would like a word.
| runarberg wrote:
| Agreed, and to make matters worse if you mess with the
| display property on any of the table components (<table>,
| <tbody>, <th>, <tr>, etc.), or position them anything other
| then static, you loose the accessibility layout. Meaning that
| you must explicitly set the role (e.g. <tr role="row">, <th
| role=columnheader>, etc.) or else with assistive technology
| wont be able to navigate the table intuitively.
| asddubs wrote:
| i wish they would at least add colspan/rowspan to css.
| doesn't cost browsers anything to implement, would make
| responsive tables a lot easier
___________________________________________________________________
(page generated 2021-05-16 23:01 UTC)