Well, it's a problem of mixing data and visual elements.

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.

Thanks for introducing me to the concept of the scene-graph.

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.

The site you work on is blank if Javascript is turned off. I do not see anything in particular on the home page that should require Javascript to render.

Me neither but I didn't decide on the site architecture. If I did, it would work.

> input button is hidden using CSS tricks because the actual button can't be styled.

Buttons can be styled.

Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.

You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily.

    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();

No stupid styling hacks needed. At most you may need tabIndex on the <a> or <div> that represents the button for selecting files.

You can leave <input type=file> around if you want to submit data via <form> and not via XHR.

>No stupid styling hacks needed.

You’ve just replaced them with stupid DOM hacks.

Not a hack, just regular API.

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.

That would have saved me a ton of effort if I had known that before getting started. Thanks, I'll keep that technique in mind for next time.

Please don't do this unless you also handle dragging files on it.

That's another issue easily solved by DnD API modern browsers implement. And should probably be done differently with regards to UX depending on whether the clicky part was a button, or a larger upload area.

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.

Heaven forbid your buttons look like buttons.

The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?

Why does there even have to be a button? I want an API not a button...

> The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?

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....

Question, is the point of HIG-compliance to make everything look exactly the same on a platform? Or is it to nail down some abstract sense of what makes UI intuitive to use?

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 point of the HIG is to make everything look and work the same on the platform: https://blog.prototypr.io/rediscovering-apples-human-interfa...

> “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.

Yeah that looks like it's always going to be fighting an uphill battle when it comes to the web. Native apps, certainly. But without an order of magnitude more professionalization of the workforce such that they can fight against business and popular trends, we're stuck with what we have.

This will never work because each browser has its own idea of how native controls should be rendered, even within the same platform. The link you posted even has examples of this. I'm all for the idea of using OS-native controls where possible, and for native apps you should absolutely do this, but I just don't think it's feasible on the web; I believe making your controls consistent across browsers is a better goal in most cases, as long as you don't sacrifice accessibility.

Is that a problem with the file input button, or with every other button on your website?

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.

IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...

Agree! The silly file input button looks like a button crammed next to an input field. What a silly design choice imposed on us by the browser makers!

If you want to fight that fight with design, go right ahead. The rest of us have work to do.

shrug Fight web fashion all you want, I like the high rise condo that it pays for.

Not filepicker inputs. They are notoriously difficult to style consistently across browsers.

Right, I remember now.

Just thought I'd let you know, Great Big Story is running a development build of react. You save some of bundle size and performance by switching to a production build.

We're replatforming for a redesign and so that should fix that, but thanks for the heads up. Just about all maintenance on the current site is on the back burner atm except for GDPR stuff.

What do you mean by "semantic" markup? The markup in the file upload widget you describe is rather generic (label, button, p or span, presumably div) but almost completely meaningful (caption, button text, file name, widget/drag and drop target), not a div soup; I don't see how you could improve it.

> but we have so many weird little needs to introduce elements just for styling purposes.

I think this is the number one reason why I prefer mobile dev over front-end web dev.

The whole debate between semantic markup and visual styling in CSS looks to me to be a massive exercise in people yelling past each other and needlessly making all life difficult.

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.

Works in all browsers, maybe, but certainly not all screen sizes. On my 1080p 5" nexus 5x, opening the page leaves me with unreadably small text. If I zoom in, the text doesn't reflow. So now I need to bounce scrolling around from side to side to read a line of text.

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).

Ha! I should have said the technique works. I'd obviously want to lay things out a little smaller on phone screens. Though, for that particular use, is just punt and say not supported on smaller screens.

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.

Sure, max-width will restore reflow, but now your code listings and images break out of their container: https://i.imgur.com/utCVxg1.png

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.

Right, I agreed that what I did would not scale down to small screens. Nor will it work if you ever try and display on an apple watch or some such. The max-width would have just given you flowing text. I fully expect the visualization to be broken on small sizes.

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. :)

Went ahead and flipped both of my "width" overrides to "max-width". Amusingly to me, the worst part of the pages, now, it seems is the MathJax stuff. That said, I'm not seeing an obvious difference in my mobile firefox, just chrome. Still not entirely sure how I would even want these to look there. If you have a good pointer for a site that styles code decently on mobile, I'd love to take a look and see about emulating/stealing.

I like absolute positioning but it's really hard to learn how to use fluently. New devs need to be educated on the concepts otherwise you get a total mess.

Flex and grid are more intuitive so they're easier for juniors to train up on.

How is it hard to learn. Put someone in front of some graph paper and let them layout what they want the page to look like. Get someone a little more experienced to help them pick the points that can grow, and off you go.

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.

I think the main difficulty is twofold. First there's the box model, which was different in IE than in the rest of the world for a long long time. Juniors that don't understand the difference will produce markup and styling that work in one browser but not the other. Absolute positioning is way more sensitive to the box model than other kinds of layout.

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.

Agreed it is no panacea. I still feel it is much more sane than most alternatives I've lived through.