I agree completely, but hiccup rather than html.
HTML First
281–290 of 551 posts
Re: HTML First
#282Earlier quoted context omitted.
Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives. But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your override…
I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying. Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick. But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute…
A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS.
>Classes that appear later in a class attribute take precedence over one’s that appear earlier.
This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
Re: HTML First
#283Earlier quoted context omitted.
The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.
Big project =/= Big company e.g. WhatsApp back before the acquisition Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.
nb I'm not agreeing with your original hypothesis.
However I'm taking about even lower down the food chain than this.
Re: HTML First
#284Earlier quoted context omitted.
Agree. I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities. Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps. With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the f…
Perhaps web publishing shouldn't be presupposed to be 'software development'?
But very often it is software development. And there isn’t always some bright line between them.
Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications.
Let’s use software development tools, rather than web publishing tools, to develop that software.
Re: HTML First
#285Earlier quoted context omitted.
Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…
Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.
Well fuck them.
Re: HTML First
#286I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react. My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use do we get a datepicker across browsers? (Looks like…
Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…
I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to select a range of dates, and even that's often different to the one I want to use to select the two dates of a return journey.
Of the classic form controls, choosing a date is probably the one that has the most application-specific needs, and therefore the one that I would most expect to vary between applications.
Re: HTML First
#287aka make your website look like shit because half the default elements can't be styled
Re: HTML First
#288I agree with everything but inline javascript
Click Me
This is going to be problematic when it comes to debugging. I still think scripts should be in a file and loaded in the header.
Re: HTML First
#289Does anyone else find that blue tint on the top of the page makes it really hard to read? I guess I usually scroll the text I'm reading to the top...
Re: HTML First
#290I agree with everything but inline javascript Click Me This is going to be problematic when it comes to debugging. I still think scripts should be in a file and loaded in the header.
It is going to be problematic when it comes to refactoring. "Can you make the button's parent container green" request comes in. Now you are hunting through CSS selector going up and down the tree. "Can you put the button that goes green into this page". Now bam! The CSS selector you used breaks as there is another element to confuse the query.