Tasks That Can Be Done with Pure HTML and CSS
256kilobytes.com
256kilobytes.com
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
Not a deal breaker functionally speaking, but sometimes a subtle transition is useful so as to be less jarring.
Can not put a price on accessibility though (screenreader, forced IE use, etc.).
Especially for content websites I don't think there is a non-economic reason to justify non-accessible content.
This does not work in Firefox, either.
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.
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.
So yes, you are finally doing UI development like it is 1998.
Congratulations.
Sarcasm aside, want to know what a proper GUI toolkit looks like? Take some time to play around with Qt.
Including accessibility? For that reason alone I think it makes sense to use the most high-level built-in features available.
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.
engineers don't get to go around running saying "i was gonna put some basic safety procedures in there, but they just wouldn't pay for it"
you make them pay for it
It takes time to meet compliance standards, and when it comes to items like color choice, often you're against client-selected requests.
I can either 1) keep pissing into the wind only to eventually be put through the grueling algorithms grind of job-searching again...
Or 2) keep firmly pressing for better standards, but still do what I'm told to do.
The sooner we come to terms with our situation, the sooner we can work to better it.
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.
Now, if you're talking about solving the above first, I'm enthusiastically all ears..
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.
I know, I know, pipe dreams.
There's plenty of people and jobs titled Software Engineer (or QA Engineer, or Site Reliability Engineer, etc).
You can't misrepresent yourself as a P. Eng. however. Here in Ontario, PEO will probably nail you for it:
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):
http://www.peo.on.ca/index.php/ci_id/2266/la_id/1.htm
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):
http://noc.esdc.gc.ca/English/noc/ProfileQuickSearch.aspx?va...
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.
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.
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.
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 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?
"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.
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.
Would it burn social capital to tell the client about a cheaper option? I thought people loved saving money.
- 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.
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.
Film at 11:00.
<!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>
If you cut out the inner document and put it in a file, you can open it and see the useful content.
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.
This is probably the reason. There are still browsers out there that don't support it 100% to the spec.
I'm keeping a beady eye on my stats, awaiting the day and can make a site entirely with CSS Grid.
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.
Its bugs are well-documented, and most have workarounds https://github.com/philipwalton/flexbugs. Even inline-block can serve as a fallback, if you can avoid whitespace around tags in the markup (https://css-tricks.com/fighting-the-space-between-inline-blo...)
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.
https://alistapart.com/article/the-story-of-css-grid-from-it...
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.
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.
At my last job we called it "divarrhea"
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.
Sigh.
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 already knew all of these things and this is a bad article.
> - Probably Someone
Here's a screencap of the post's HTML source with no markup, for the time being:
https://i.imgur.com/2CGG48Q.png
Edit: Or use the archive.org link spzb posted.
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's basically a modern pure HTML browser. With images even. Well, sometimes. If the site's markup isn't garbage.
That's white, no?
In 2019, caniuse.com says scroll-behavior is not available in Apple Safari or MS IE/Edge:
https://caniuse.com/#search=scroll-behavior
None of my friends with iPhones install Firefox or Chrome on iOS. They all just use the default Safari browser.
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.
Even if they did, those browsers use the safari rendering engine under the hood, so they'd have the same issue.
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.
If you go to the website in OP and click the table of contents in Chrome and then Safari, you'll see the difference.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-beha...
Crazy how they don't let you use a curve to define your own timing.
So many contrast issues (166 X Very Low Contrast via the WAVE tool) , I can't read this site.
please, give Accessibility a try. https://wave.webaim.org/extension/
Putting white text on a light blue background, apparently
(tr) > td img.emoji { padding-bottom: 1em; }
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 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.
Just error for me.
I’m curious if you’d be willing to share roughly how many votes it earned you? I wonder how the rest of the community responded to it.
Only it’s not a WordPress site.
Using the hidden checkbox/label css hack to make non-js collapsers is something I'd love to get away from since it can confusing for accessibility.
[0] https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Brow...
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.