Tell that to all 50,000 people in my company, and the product owner I'm working for, who are forced to use it by Infrastructure, and 0.0% of our customers.
typically I still see 5% IE11 users for the regular consumer sites I touch. however much I want to not support IE there is no way to motivate it from a business perspective.
Depending on how much it costs in extra developer hours supporting an older browser it might actually make quite a bit of sense for many companies, especially smaller ones without a well established product.
One thing I myself found out only recently was that you can do validation of inputs directly with HTML. Eg adding type="email" will validate the input for email or you can use custom pattern with regex to validate them as you'd like. Granted with regex it gets pretty messy but in general it's a good first version if you don't have specific UI requirements for the error messages. Also I think the errors are automatically displayed in the user's system language. https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_i...
That, imho is the biggest reason to use the newer types. It annoys me to no end when I have a numeric PIN or 2FA entry that brings up the regular keyboard where numeric input is obscured.
Using built-in html primitives seems like such a good idea in theory, but when you have requirements that dictate a certain layout, or behavior on those elements you discover that some things you can't do, others you can only do in certain way, maybe in some browsers. Latest example of this is native input type=date: I want to use it every time I am tasked with making something that has date input, not once did it offer flexibility to meet the requirements (you can't format date, I don't think there is a way to hide clear button on ff, no duration input, etc...). Next time I'm just not gonna bother and reimplement all of it myself.
Accessibility is a second-class citizen for a lot of clients, therefore a lot of web agencies. In my two years working in one, only once was I tasked with a fully accessibility compliant site, and that was because it was government subsidized. Clients will gladly pay to move buttons and complain about a particular shade of blue or opacity transition speed, but god forbid we deliberately put any hours towards making the site accessible. We could try all we want to talk them in, they were the ones who paid in the end, and most of them just don't give a crap.
Most of our devs were pretty thorough about doing the most they could in the given time frames anyway, but it pretty much never was made a priority.
Also, conspiracy theory, contract development has a bit of a moral hazard problem when it comes to these sorts of issues.
On one side, we have the option that helps guard clients against accessibility issues and any problems that they might (though not necessarily will) engender, and is likely to be more maintainable in the long run. But it would also require fewer billable hours to build. And it's not what the client asked for in the first place, so there's the risk of burning social capital in trying to even suggest it.
Alternatively, you can get paid more money to supply the client with more immediate gratification.
>But it would also require fewer billable hours to build. And it's not what the client asked for in the first place, so there's the risk of burning social capital in trying to even suggest it.
Would it burn social capital to tell the client about a cheaper option? I thought people loved saving money.
I agree with you. This is all benefit for everybody:
- You provide a cheaper solution,
- You provide a solution delivered faster,
- You can bill more per hour without the client even knowing: "you have solution A, which is exactly what you ask for, that will cost $20k and will be delivered in 30 days, or solution B, which is very close to your requirements, that will cost $10k and will be delivered in 15 days", but option B only takes you 10 days, so you are paid $1K per day rather than $667.
This is really why we need to form a professional association of some sort - it'll allow for some level of responsibility in what developers produce, as well as help guarantee a certain standard of product.
It will also ensure that the we don't have to worry about the market being flooded with cheap labour that every big business and government entity seems interested in creating.
I understand that doesn't sound great right now given that software development is a comparative goldmine to a lot of other jobs, but compared to other professions we could stand to become more formalized.
That can't happen because there's no formal qualifications to calling yourself a software engineer. I've worked with people hired as software engineers who just took an X week online course, and it shows.
Now, if you're talking about solving the above first, I'm enthusiastically all ears..
In Canada most software devs don't call ourselves engineers - we legally can't - engineer is a protected title.
And yes, that's what I'm suggesting - there needs to be a formalization of terms for software. I'm not saying exclude the X week course individuals, but in Accounting there are "tiers" of accountant, based upon education, focus, and experience, and that may need to be instituted, allowing people to see at a glance what designation you've achieved, even if that means the bootcamp grad has to write a 50 question test at the end of their X weeks.
Though from what I understand they frown on it because they want complete ownership of the term (but their critique really has no teeth unless you make like you are indeed licensed by a central regulatory body such as PEO):
edit: Just some further information on the subject in Canada—Software Engineer (among others) is a nationally recognized and distinct title (can overlap, but doesn't necessitate a P.Eng certification):
It looks like if you want to call yourself an engineer nationally you need to be a P.Eng, and it's up to the provincial bodies to regulate the usage in each province.
> Experience as a computer programmer is usually required.
That's amazing, you need to be an engineer, but don't need to know how to program to be a Software Engineer.
I took a different interpretation than your first conclusion there.
It sounds like you can call yourself an engineer all you like—particularly with relation to software. There appear to be no hard requirements.
However if you want to bill yourself as a Software Engineer and work as a Professional Engineer (the protected title in Canada) then you must have your P.Eng.
Similarly: A Software or IT Architect isn't required to be certified by the CACB. Nor does a Web Designer need to be a member of the GDC.
So— all Professional Engineers could bill themselves as Software Engineers (situation providing), but not all Software Engineers can work as Professional Engineers.
Ah, ok. Good point. It's really down again to the provincial regulatory bodies to decide how uppity they want to be, but in Canada Federally there's no restriction unless you're trying to act as a Professional Engineer.
> That's amazing, you need to be an engineer, but don't need to know how to program to be a Software Engineer
This isn't actually that non-sensical when you consider how being a PE works in other disciplines. You're legally responsible for reviewing and approving design documents, but you won't be doing all the work by yourself. You'll have a team reporting to you, and you sign off on their work. In the case of software, you don't necessarily need to be a programmer to review the design and high-level aspects of a program.
The first step to getting a protected title is forming a trade association. You can't call yourself a lawyer without approval of the Bar Association. You can't call yourself a doctor without approval from the Medical Board. The first step to getting "engineer" as a protected title is forming a society of engineers who can petition the government to legally protect the title.
Well, there's a difference between "doctor" and putting "MD" after your name just like there's a different between "engineer" and a "PE".
I'd question if anybody really gives a damn if a software developer is certified with some feel-good namesake. Most software just isn't as serious as needing legal counsel or medical expertise.
Also, many of the roads I can think of where we do arrive at a place where people care about some certification are pretty terrifying. Like needing years of schooling before you can legally make a Twitter app for somebody, or needing re-certification to make tiny lateral moves like you need in the medical industry.
>Most software just isn't as serious as needing legal counsel or medical expertise.
Most legal counsel and medical expertise isn't that serious either. Ask your family doctor how many patients they have every day who come in only to be diagnosed with the common cold, something anyone's grandma could diagnose over the phone and treat with a microwaved can of soup. But when it is serious, you don't want grandma doing your appendix surgery. You want a licensed and trained doctor.
For every one slippery slope argument, there's five "it's not that slippery" counter arguments. You don't need a medical license to buy over-the-counter painkillers, so why would you need a software license to build your own software? You don't need to be a bar-certified lawyer to write your own contracts, so why would you need to be a certified software developer to make a website?
Heck, take plumbers for an example: there are certified, bonded, and insured plumbers. There are plumbers who are not. You can choose a non-certified plumber, but most people would choose the certified plumber instead. If you don't need a certified software engineer, you're not going to pay the premium they would charge with no guarantee of quality. In this world, networking is king and if you don't know someone, you're screwed. If you need certified software, you'd hire certified software engineers and pay the premium and know you at least got someone who has passed their certifications and if they do poor quality work can have their certification revoked.
Considering poorly built software can bankrupt someone, publicly embarrass someone, and can even kill someone, the fact that anyone willing to lie on their resume can build it is scary. You can be reasonably assured that the surgeon operating on you is quality and there are ramifications if they are not. Are you sure that the person who wrote the code for your car's anti-lock brakes or airbags are held to similar standards?
This is part of what a legally protected engineering title does. When you stamp something as a professional engineer, you are saying that it meets all applicable codes. That is a legal statement, and to do otherwise would be fraudulent. If you have a professional association that dictates this and has restraint of trade in place so only a member of the professional association can do it, then it's not even pushing back. It's a flat statement: "You have to do it this way or you can't have it stamped."
Have you had luck in this endeavour? As it stands most software devs aren't actually engineers and as such are held to no ethical standard, nor have the (professionally certified) credibility behind their words to demand specific design standards.
Software engineers, unless they literally went through a b. eng., are not engineers, despite calling themselves that. Most software/web developers are just wage workers.
"You make them pay", you being who exactly? The employee that gets a list of requirements and a deadline? These places are filled with juniors with relatively low experience. If their bosses tell them to do something, they'll do that thing, and don't have much leverage to argue.
I’m not sure it’s frowned upon. I think most people look at it as almost no reduction in revenue/users but a massive investment. It’s a damn shame, too. I think every developer and designer should always have accessibility in mind.
My own reason for not doing it myself lately... the built in browser behavior is, or should be the expected behavior for what the user is using... I'm not going to "fix" that for them. As much as I don't like the various inconsistencies between browsers on Date input controls let alone time.
It's something I don't think anyone gets right.. I think MS Ajax Toolkit came closest imho, but that didn't include a prescriptive time input and too small for tablet/phone input.
Native elements work if your design spec is flexible and aims to look natural on every browser and platform. If you have a rigid design they aren't as useful.
Wouldn't be the end of the world if browsers actually exposed all of the relevant styling, but it does help to try and make flexible designs. HTML primitives make it a lot easier to reach accessibility spec.
The date input in particular really is a mess though, every platform does it differently and phones have all sorts of weird widgets attached to it.
Date input is a mixed bag... it sucks all browsers/platforms do it weird and in incompatible ways... on the flip side, I don't like interrupting the "expected" platform behavior in terms of accessibility users.
Web development is such a pain because the standard is sub-par (decided by committee, so no surprises there) and the implementation is even worse (full of inter-vendor inconsistencies and missing features).
Frankly, last time I did web development, I felt tempted to just make the entire page one screen sized canvas and implement my own UI toolkit on it. That's bound to be more reliable (and probably faster) that the current state of affairs.
The actual page source is very funny. In the middle of several thousand lines of drivel is the actual content.
At line 1732:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<body>
<p>Here are some things that are built into the HTML and CSS standards that you probably didn't know about.
Or maybe you did. Congratulations.</p>
... (about 25 lines with all the real content)
</body>
</html>
Yes, there's an entire HTML document in the middle of the document. Which is just wrong. Then there's another thousand lines of HTML. And yes, there's Javascript.
If you cut out the inner document and put it in a file, you can open it and see the useful content.
Looks a bit like server side includes done wrong. Accidentally include the head/body/non content tags in the include, import them into the main file and well, you end up with duplicates.
Firefox at least interprets that as an ordinary include, rather than as a subdocument like a frame or an iframe. You'd think that <html> would start a new context, with the defaults for a new page. But it doesn't.
Was hoping to see some examples related to CSS animations or interactivity, instead got just a few tricks that don't seem all that useful. Also, the way colors were chosen for this website makes my eyes instantly hurt.
It's sad it doesn't get more use. Potwntially this is because CSS frameworks hide all this away and nobody is really learning CSS anymore but I wouldn't really know. I'm not really that exposed to the web front end side of things.
Before CSS layouts, HTML tables were (ab)used for layout and were functionally very similar to what CSS grid is now, except responsive of course. In hindsight, maybe tables for layout weren't wrong.
> What a lot of developers need to understand is that HTML shouldn't be use for layout. HTML should be use for semantic and information structure.
That was the great lie of the 2000s. It was oft repeated, but almost never adhered to. CSS Zen Garden was cool, but the typical attempt at "separating content from presentation" almost universally resulted in a div soup that was even worse than table layouts. If a div exists only to hang a class off it, so that it can be targeted in CSS, it's a part of layout, not semantic/information structure.
In a perfect world, in which most websites were not actively user-hostile, we could have separation of layout from content. It would include relinquishing control over rendering back to the users. It would require to stop obsessing so much over colors and layouts and custom controls. The very concept is anathema to the modern web, though.
> If a div exists only to hang a class off it, so that it can be targeted in CSS, it's a part of layout, not semantic/information structure.
Thanks, I've always thought this intuitively but never seen it written out.
Just as any academic theory hitting the reality through actual implementation, the theory should be more of a guiding force instead of a rigid structure to follow.
Much like how the military learned to plan battles (No battle plan ever survives contact with the enemy - Helmuth von Moltke the Elder) by giving troops higher-level objectives, rather than planning every single step of the attack, such as exactly where they should walk and hide, and expecting them to follow it to a T.
This is how I approach most programming/web design theories... including BEM.
The problem is that, yes, this is the ideal, but when the ideal ran up against the real world usage of these tools, two things happened, one inevitable and the other just a bad choice:
1) a small, extremely vocal group of devs kept reminding us this while the rest of us used the standards "wrong" and did fancy layouts and things,
2) seeing how most of the world used the tools we had, the standards folks didn't give us good layout tools or application development tools, they gave us CSS and it took browser vendors like Microsoft to give us XHR.
Oh what I'd give for the standards folks to have taken some time to look at the world being built around them, and then given us a better way to do that, instead of "HTML shouldn't be used for layout" for years.
I feel like, had things gone in a different direction, web development now would be as easy as VB/Delphi/Lazarus (hell, even tcl/tk) once made desktop app development. Instead, we get the soup of languages, build tools, and the confusing mess of modern web dev.
I currently still use tables everyday in my job as an email dev. Tables might not be "wrong" but they have serious limitations that have to be worked around.
There's no reason to not use CSS Grid, except for not knowing it well enough — and there's no reason not to learn it.
Of those, only IE11 is relevant, as it's a desktop browser, on wider and taller viewports.
Most of these browsers are mobile browsers on devices with narrow viewports, so even the default `display: block` fallback may be sufficient. If you have margins/paddings/widths etc which only make sense in the CSS Grid version, you can set these properties inside an `@supports` query https://developer.mozilla.org/en-US/docs/Web/CSS/@supports
For IE11, it's a choice of presenting visitors with a slightly worse layout, to match the browser (https://philipnewcomer.net/2014/04/target-internet-explorer-... or, if you use Sass or PostCSS, using mixins that output CSS Grid properties with Flexbox as fallback.
A reasonable fallback doesn't need to match CSS Grid exactly. The whole point of media queries and responsive web design is that the website won't look exactly the same on all devices; it will look and work as good as it needs to look in that specific device.
My last workplace's policy was to fully support the last couple version of Edge, Firefox and Chrome, but for IE11, it was "it won't be utterly unusable". That approach is becoming more and more commonplace, too. Reasonable fallbacks doesn't mean being perfect, either. I'll be honest anyway, most people still using IE11 these days are either literally stuck with it, or a pretty used to half the sites they visit to be a bit broken.
Not a lot, though. Edge, Chrome, Firefox, Safari, Opera, iOS and Android all support it. Nobody cares about Opera Mini and Blackberry, and the sooner we cut IE11, the better. It's never going to support most of the modern standards.
It's not that nobody cares about Opera Mini, it's instead that OM users (like me!) have come to accept that some sites will behave in a weird way on the browser, and so it might be necessary to switch to a different one. It's the tradeoff we make to get all of the good things that come along with OM usage.
“Recent-ish versions of Chrome, Firefox, Safari, Opera, iOS and Android all support it”. According to my stats, there's a load of old Chrome & Safari versions using my site that would be tripped up by its use, sadly.
I'm keeping a beady eye on my stats, awaiting the day and can make a site entirely with CSS Grid.
This is basic HTML5 literacy. At the end of the day the new HTML5 and CSS features do not fit into out dated work practices and the excuses that go with it. Web content creators and developers should be familiar with all of this stuff and not kidding themselves that the 'sea of divs is the way to go because we do really important projects and need to have polyfills back to IE6'.
Not using the new tags and not using CSS grid is a bit like only eating fast food and no longer knowing how to use a knife and fork. When I look at div soup I know that the team behind the page have not got it yet. None of the div soup HTML is maintainable. It is dated. So any 'wow you can use the details/summary' article comes across to me as 'wow, you have learned to wipe your own nose!' This whole industry needs to get to grips with the lingua franca of the web, focus on document structure, use the stuff that works in evergreen browsers and move away from big up front visual design made into div soup to content driven design. It is that simple and excuses are pathetic.
I am hopeful for CSS grid. I am hopeful that we can properly return to the principle of separating concerns. I am so tired of dealing with sites that have HTML littered with divs and spans solely for the purposes of layout and styling.
I created a pure CSS stopwatch last year. Was a bit of a brainwave in the shower after I had been playing with CSS animations. I was quite surprised how well it turned out, it works exactly as I imagined it would.
This screenshot is great, and really makes another point: if you remove styling and JS, you'll probably end up with a more useful and not infrequently prettier page.
Sometimes I prefer to view sites from Google cache, because I can quickly tap text only and it works great.
I'm more and more thinking about a modern pure HTML browser. I sometimes use links -g and it's amazing how fast and clean the experience is. Sites that don't work can go fuck themselves. Modern browsers are no longer _user_ agents, they are webdev agents.
It would help if he / she noted how supported these things are. That is, just because it's in the spec doesn't mean all browsers have implemented them, or have done so in the same way.
Yes, each of us can. We know this :) My point is, it makes __a lot__ more sense if those essential details are in the article itself. The article becomes more complete and there's less wasted collective time.
> The opacity/transparency of rgb colors can be adjusted by using RGBA colors. Ex: rgba(255,255,255,0.8) is black that is 80% opaque (20% transparent).
Does Safari on iOS need to support this feature? Because isn't the entire idea of smooth scrolling to implement the scrolling that was ALREADY natively implemented on iOS?
Basically, while Safari might not "support" this feature, they already force their version of smooth scrolling on every site inside their browser.
On Safari for iOS or MacOS, you already get smooth scrolling no matter what. So they might not support the spec, but you still get it no matter what.
The only explanation I have for IE/Edge is that it is IE/Edge, and no one really expects much from those browsers anymore regardless. If I had a nickle for everytime someone told me "IE doesnt support that", then I wouldn't need a day job.
Lastly, this isn't a critical site feature in most cases. If an IE user uses your site without smooth scrolling, will it really impact their experience in any way? Probably not. So this is an example when you can safely use this feature, the browsers that support it will offer nice smooth scrolling, and the ones that don't will offer the same experience that those browser users are already used to.
The smooth scrolling set by the "scroll-behavior" is not the same as the user initiated scrolling in iOS. It is scrolling behavior when triggered by a navigation API [0].
If you go to the website in OP and click the table of contents in Chrome and then Safari, you'll see the difference.
It's smooth scrolling when triggered by an action such as a fragment link or a JavaScript API, it's not referring to manual scrolling (eg scroll wheel, touch swipe).
I agree, I don't think this is a feature that web designers should worry about. How I scroll is something that should be set on the browser level.
This is sort of like a web designer writing CSS to redesign my browser tabs while I visit their site. This isn't their job.
Plus, on Mac devices with trackpads, the system OS already adds a smooth scrolling to all actions we do. So when we visit these sites that add smooth scrolling with Javascript it can cause us to go insane. Because scrolling becomes insanely sensitive, with 2-3 inputs trying to control scrolling behavior (the OS, the browser, and now JS). The system is adding its own acceleration and deceleration, and then javascript is sitting on top of that trying to interpret these forces and add their own multiplier on top of those. I have visited sites that have JS implemented smooth scrolling that is so sensitive, that I can't even barely touch the trackpad without scrolling down an entire page length.
Except for the occasional side project, i don't dive into html/css more than the basic that is necessary...but today i learned about the available html toggle (the details element); nice little treat to start the day. Thanks for sharing!
Here’s a thing I can’t do with CSS combinators, and I’ve always been curious why: apply rules to an element that contains any elements matching the criteria. E.g. (hypothetical Regex-like syntax):
(tr) > td img.emoji { padding-bottom: 1em; }
...would take any table row containing a cell with an image in it, and pad the table row itself a bit more, so as to balance out the image which is slightly larger than the text height.
The lack of this feature doesn’t bother me so much when actually developing for the web, but so many web scraping libraries offer CSS-selector accessors as an alternative to/replacement for XPath accessors, and when using these libraries, the need to grab the container element of the thing tagged with something (where the container itself has no distinguishing features other than having such a child) always results in inefficient spaghetti compared to what could potentially be a very simple selector.
Anyone know why we don’t have these? Something to do with the cost of rescans on DOM changes, maybe?
This is because the CSS spec is consciously written so that you only never need to look forward when parsing the DOM. For the same reason there is no follow sibling selector, only previous sibling (`~`)
This is a major performance factor, since it means all layout can be done in one pass. If the proposed selector were added. CSS layout would have unbounded complexity.
One thing I think is missing from the current html spec is having a src attribute on select tags. Would be nice to be able to not have to define the options directly on a page and instead serve them up dynamically. Not a big problem off course, but it seems like something that is missing.
Thank you. I won't go into specifics, but surprisingly it was much better received than my claims that one can actually have self-hosted mail system that does not deliver your mail straight into gmails' spam folder.
Same here. Funny to see how the /. effect - or, in this case, the hug of hn - still kills websites when cache plugins, static sites, varnish (sw), nginx fastcgi cache are all available and fairly simple to set up.
I blame wordpress for not shipping with built-in microcaching.
Can't vouch for how good they actually are, but I found this [0] list a while ago with various polyfills, including apparently 7 different polyfills for <details>.
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@256kilobytes.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
In my narrow mental model I've always heard the claim that HTML and CSS is the purest form of document representation. A static site that can not get any more lean then that. And yet after removing the JavaScript (the source of all evil on the net) the site still can not handle the traffic and offers a 500 internal server error!!! Really? they can't serve static HTML on a site that is promoting static HTML features?
Smooth scrolling CSS: Not IE, Edge or Safari. https://caniuse.com/#search=scroll-behavior
HSL: Everywhere. https://caniuse.com/#search=hsl
Details element: Not IE, Edge. https://caniuse.com/#search=details
Progress element: Everywhere. https://caniuse.com/#search=progress
Meter element: Not IE. https://caniuse.com/#search=progress
CSS variables: Not IE. https://caniuse.com/#search=css%20variables