In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist.
In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph.
That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems.
I tried to make an argument on a React community slack that components are purely visual, that they should express the visual structure of the web page, in the context of an argument over how state and props should be used.
He hated the rise of the Redux ecosystem, and I was trying to make the point that if you don't manage global state in your application sanely, you'll only end up reinventing it poorly, passing onChange across the Atlantic in the case where your save button doesn't live in the same visual space as the rest of your form.
His response was to bring up the Router component to make the point that not all components are visual.
UIs are complicated things, I've found that the visual model is the best encapsulation concept. Components aren't bad, but you need to first have a need to use them, because there's definitely a tradeoff, and second you need to use the right abstraction techniques. Routing components are a hack, different pages should just load different base components in the site backend.
But it seems like once someone swallows the functional paradigmatic koolaid, they lose all perspective to see when the paradigm fails to produce erudite design.
Buttons can be styled.
let i = document.createElement('input');
i.type = 'file';
// other attributes if you like
i.onselect = ev => {
// ev.files contains selected files
};
i.click();
i.remove();
You can leave <input type=file> around if you want to submit data via <form> and not via XHR.
You’ve just replaced them with stupid DOM hacks.
You clearly never implemented any of the above stupidity with file input styling and overlays and passthrough of events, and different unchangeable widths of file inputs you had to account for in various versions of browsers, and bugs in specific browser versions, and discontinuity in the input field clickable surface so part of the button is not clickable for no reason whatsoever to the user, so that everything works as expected in E6+IE7+IE8+IE9+FF1+Sfari,... to think it's even comparable on the hackiness scale.
Frankly, I don't find the original UX of dragging files onto an upload button all that intuitive. So instead I add drop functionality to a larger container in my apps. So if I have dialog that accepts files, users can drag files anywhere over the dialog and the dialog highlights that it accepts drops while dragging.
Why does there even have to be a button? I want an API not a button...
Why don't the buttons on your website look like HIG-compliant buttons on whatever platform the user is using? That's what web chrome looked like back in the aughts and it was fantastic. Apparently you can still do it: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Th....
It seems like people with this viewpoint pay lip service to the latter goal, which allows for trends like Material Design so long as they fit with the guidelines, while really wanting the former, which to me looks like nothing more than tilting at windmills.
I'd post screenshots of our current CMS work, where we have a design staff working earnestly to make everything super-intuitive, but HN doesn't do image management so this discussion will be sadly deprived of examples.
> “The purpose of visual consistency is to construct a believable environment for users… The transfer of skills is one of the most important benefits of a consistent interface, especially for beginning users.” pg. 10
> “…consistency makes it easier for a user to learn new applications; it also makes it less likely that a user who follows habits learned from one application will make a disastrous mistake when using a different one.” pg. xi
The HIG goes beyond simply expressing principles of what makes for a good UI. The consistency in and of itself allows users to develop an intuition and muscle memory for how their computer will work. That intuition is destroyed when different apps look and behave differently. In that sense, it's better to be less intuitive according to some abstract principle if necessary to achieve consistency. It will take the user longer to understand a "more intuitive" UI starting from first principles than to understand a UI that exhibits the quirks embedded in the HIG they already know.
The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
I think this is the number one reason why I prefer mobile dev over front-end web dev.
I've ranted about this before, but worse is that everyone insists on trying to go with the default flow of elements as much as they can. Example I used last time was that it is actually easy to layout things and have them look pretty solid between browsers, iff you embrace absolute positioning. http://taeric.github.io/cube-permutations-1.html is a page where I played with laying out a Rubik's cube. I confess I have not tried it in all browsers, as I don't care too much, but it works in all of my browsers, including my phone. I shudder to think how I could have done that with just using floats and inline-block style concerns.
Why do I claim that makes it worse? Because you wind up with more markup just to trick the layout engine to calculate where to put things. Instead of you just figuring it out largely on your own and not building a Rube Goldberg machine to layout a page.
Internally for a previous company, I did this only to have the next person try to get rid of absolute positioning because "gross". Over two sprints later they caved and went back to the working solution that was a) less code, b) worked everywhere, and c) was easy to modify by virtue of a.
I suspect if I performed the same test in my 1440p 27" monitor, I'd have a surprisingly similar problem, of overly small text in a small box in the centre.
So in reality, while it may have made it super simple to preserve the shape of the Rubik's cube unfolded, it's impeded reading the main content on anything outside the range of a plus side phone to a Macbook's scaled 1440x900 canvas. And really the Rubik's cube could have been just a image (an SVG if you're worried about sharp or selectable text).
Note, I couldn't just do an image because of the animation nonsense I was playing with.
Edit: though, oddly, I think you are really complaining about some of the styling I inherited from org. I can possibly fix that easily enough. Never tried. Pretty sure I can just swap out a "width" with "max-width" and things will reflow as desired. For my eyes on my phone, the current width was fine. I didn't bother checking why it killed reflow. But I can confirm it reflows as desired on desktop if I do that.
My point is that absolute positioning/pixel perfect designs are easy because they solve a simplified project "How to have my content look correct at a fixed size". But it breaks down once that fixed size is no longer reasonable for the target device.
I contend that is just not a requirement for most things. This particular endeavor mine, included.
So, what point are you arguing against? If it was that I pitched this strongly as a panacea. I definitely concede it is not one. But I also don't believe in panaceas.
If if it is that there is an easier way to get that layout such that I can play with it in silly animations without absolute positioning, I'm game to see it.
Edit: I should say thanks for getting me to look at my own site again in a long time. The code block would need the same width->max-width flip. Though, I question on why anyone would look at that page... well, ever, first. But in general even on a small screen. Not sure what I want code blocks to do there. Will take another look sometime hopefully this weekend. :)
Flex and grid are more intuitive so they're easier for juniors to train up on.
Not to say that they can't do better with flex and grid. But it was like our entire industry didn't even bother trying to learn with the first tools that our industry made.
Second, unless you really want to insist on absolutely positioning everything, you're just going to need elements to flow occasionally. Most devs just aren't going to get a granular enough understanding of how absolute, relative, and fixed positioning work to where they can mix up the two to form fluid UIs.
They'll make one mistake and not realize it and before you know it behavior starts an inexorable slide in sanity, from which the only recovery is to scrap the entire page and start over. Been there done that.
It's the same reason why divs won in the first place. You can't dictate the shape of a document to people and it be anything other than a kludge.
Take the site I work on, Great Big Story[1]. We have sections and headers, but our content isn't defined by text, it's defined by graphics and videos, with little metadata sections on the video player page that I suppose could be semantic if we had the right descriptive tags. I use semantic markup when it seems to make sense, but we have so many weird little needs to introduce elements just for styling purposes.
Take a recent example, I need four elements to make a styled file input form. Two labels, one to look like a button and can be clicked, taking advantage of the browser behavior of treating clicks on the label to be clicks on the form. The other label is the actual label, could be just a span if I wanted, it doesn't have the htmlFor attribute set. The actual form input button is hidden using CSS tricks because the actual button can't be styled. Finally there's the filename display, which is set to the filename of whatever was uploaded or the existing one if present. This uses Javascript callbacks to get set.
None of these elements are semantic, legacy cruft keeps the markup from being simple and readable. I suppose you could demand our video presentation site to be a motherfucking website[2], but I fail to see how that will actually improve much of anything and would just hurt our brand. I'm getting a little tired of coder hatred for web fashion. It keeps us all employed.
But I think we're at least 10 years out from being able to actually use semantic markup. Web standards and browser vendors still have some maturing to do.
[1] https://www.greatbigstory.com
[2] https://motherfuckingwebsite.com/