planet.webcompat.com

otsukare by Karl Dubost at

I'm a uBlock and uMatrix user with a very agressive setting. I block everything. It makes the Web faster, more performant, less prone to bugs and security issues. In my text only version of the Web, there are surprises. Sites entirely made of JavaScript which are not at all readable. It's a kind of Occam's razor where it helps me decide if I should spend time to configure my browser to make the page more readable. If the cost/benefit ratio is too high, I just ignore the site.

But let me introduce you to the "Fatwigoo", an interesting animal which is populating the CSS-less and JS-less landscape of Web pages. You can choose to pronounce it "Fa-twee-goo" or "fat-wee-goo". I prefer the latter. You can partly reproduce the screenshot (below) with going to this article on A List Apart with Firefox and select in the View Menu ➜ Page Style ➜ No Style.

These are created by the inline SVG in the page. These SVG icons are stretching by default to the width of the viewport. Nothing wrong with that, but you can improve the rendering for people like me who prefers sad-boring-peaceful web pages.

How To Solve The Fatwigoo

The icon for twitter in this page is represented by this SVG.

<svg
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px"
    enable-background="new 0 0 274 224"
    viewBox="0 0 274 274"
    xml:space="preserve">
    <path d="M273.7,27.2c-10.1,4.5-20.9,7.5-32.2,8.8c11.6-6.9,20.5-17.9,24.7-31c-10.8,6.4-22.8,11.1-35.6,13.6
        C220.3,7.7,205.7,0.9,189.6,0.9c-31,0-56.1,25.1-56.1,56.1c0,4.4,0.5,8.7,1.5,12.8C88.3,67.4,47,45.1,19.3,11.2
        c-4.8,8.3-7.6,17.9-7.6,28.2c0,19.5,9.9,36.6,25,46.7c-9.2-0.3-17.8-2.8-25.4-7c0,0.2,0,0.5,0,0.7c0,27.2,19.3,49.8,45,55
        c-4.7,1.3-9.7,2-14.8,2c-3.6,0-7.1-0.4-10.6-1c7.1,22.3,27.9,38.5,52.4,39c-19.2,15-43.4,24-69.7,24c-4.5,0-9-0.3-13.4-0.8
        c24.8,15.9,54.3,25.2,86,25.2c103.2,0,159.6-85.5,159.6-159.6c0-2.4-0.1-4.9-0.2-7.3C256.7,48.3,266.2,38.5,273.7,27.2z">
    </path>
</svg>

Throw in there a width attribute.

<svg
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px"
    enable-background="new 0 0 274 224"
    viewBox="0 0 274 274"

    width="50px"

    xml:space="preserve"></svg>

And suddenly the icon will just be a small 50px icon in the page. It's not an issue because anyway you are already adjusting size, colors, etc. through CSS. The CSS will set the right size for the users who are using Pathécolor web pages.

Before - After

Huge…

Fatwigoo example

Lovely…

Fatwigoo example

Otsukare!

Mike Taylor's Web Log by Mike Taylor at

<select> elements have always been kind of awkard, IMO.

web-bug 12553 describes an issue where a pretty famous 3rd party library, FastClick.js turns <select>-level awkward to middle-school-dance-party-level awkward.

(In that the <select> doesn't function at all if you're on Android, unless you're using Chrome Mobile (depending on what FastClick version you're running). Just like middle school—trust me this analogy makes total sense, 7th grade was really hard for me and I'm still working through it, OK.)

The issue here is the result of a web standards interoperability failure (more on that in a second, there's a happy ending I swear) and the inability to predict the future of the web platform and browsers by FastClick (more on that now).

So if you don't know much about FastClick, or why it was so popular, put on 2012's "Now That's What I Call Music! Volume 44" to set the mood and read their GitHub page.

Cover of Now Thats What I Call Music Volume 44 album

Back in 2012, when tapping on things in mobile browsers was slow (because browsers always had a 300ms delay between a touchend event and a click event), it was cool to use FastClick to make tapping on things fast. Noted soda water critic Jake Archibald has a good article on this and how to get rid of it these days (tl;dr make your site's viewport mobile friendly).

(The article is a bit dated given that Firefox didn't support touch-action: manipulation when it was authored, but it does now, so consider that another option.)

OK, so. Anyways. The way this library works is to dispatch its own synthetic click event after a touchend event, without the 300ms delay. This is all great and fine for links. Things get trickier for inputs like <select>, because there's never really been a web standards way to programatically open them via JS.

Per DOM level 3(000), untrusted events (think event.isTrusted == false...except for click) shouldn't trigger the default action. And the default action for <select> is to open the widget thingy and display the 400 countries you don't live in.

OK, back to FastClick in the year 2012. Things either broke on <select> elements, or never worked properly in Chrome Mobile, but developers (being developers) found a workaround with mousedown events for Chrome Mobile (in a stackoverflow thread, naturally), put it into FastClick. This unintentionally broke it for other browsers, and later on some fixes were introduced to unbreak that for Firefox and Blackberry. But... that's only some of the select-related bugs.

Fast foward a few years and Chrome fixed their untrusted events default action bug, and as a result broke <select>s on pages using FastClick. Fortunately for interop, they decided to not back out the fix (except for Android WebView!).

Anyways, this blog post is getting too long.

In conclusion, if you run into bugs with FastClick, you should probably delete it from your app. It's basically unmaintained and they don't want you to use it either.

And besides, we have touch-action: manipulation anyways.

otsukare by Karl Dubost at

There is an ongoing Firefox sprint (This looks like a URI that will die in the future. Sniff.) trying to identify issues in the browsers and report them on Webcompat.

CSS in JS

We got a flood of new issues. Unfortunately a lot of them were invalid and were not part of what we qualify as Web Compatibility issues. This strains a lot on our team (usually Adam, Eric and myself doing triage, but for this occasion everyone had to join) and it is probably frustrating for the reporters to see their bugs closed as invalid. So in the spirit of "How do we make it better for everyone?", a couple of guidelines for people running the events related to Webcompat sprint.

What is a Webcompat issue?

Or more exactly what is not a Webcompat issue.

Our work focuses on identifying differences in between browsers when accessing a Web site. That said all differences are not necessary Web compatibility issues.

Before starting a Webcompat sprint (organizers)

  • Fully understand this document. If you organizing an event and have questions unanswered in this page, please ask a question.
  • Make sure to explain to participants that quality of the reports is the goal.
  • Make sure that participants have created a fresh profile.
    • This fresh profile should not contains any add-ons, except if needed the reporter extension. Developer Edition and Nightly already have the Report Site Issue button into the "•••" menu.
    • This fresh profile can be set in a way that it resets itself at each restart.
  • Encourage participants to write detailed steps for reproducing the issue. An idea is for example to work as a team. One finds an issue, write the form without submitting it. The team mate on another computer is trying to reproduce the issue with only the form instructions. If the person can't understand the given instructions and/or can't see where the issue is, then it's probably an incomplete report.

During the Webcompat sprint (participants)

Testing in Multiple Browsers

The most important thing of all. You need to test in at least two browsers. The more, the merrier. Being sure that it's actually not breaking elsewhere is a good for a webcompat issue. Sometimes it's better to ask someone else who is using a browser and compare the results.

Responsive Mode and Devices

Responsive mode on desktop browsers is a quick way to test if the website is ready for mobile devices. That said these responsive modes have their own limitations. They are not simulators, just emulators. You might want to double check on a real device before reporting.

Slow Network

If the network is slow. It is usually slow in any browsers. These do not make necessary a Web compatibility issue. Performance issues are very hard to decipher, because they are dependent on many external parameters.

  1. Try to reproduce in another browser. If it's blazing fast in another browser. There might be something interesting.
  2. Try to reload and see if the second load is faster (it should if the website has been correctly parametrized.)

Most of the time, this is not a Webcompat issue.

Flash plug-in

Some sites do not work or half work without a flash plugin. We can't really do anything about it. It might not be a good business decision but they chose it. It creates basically the same issue for all browsers. If you are unsastified with it, try to find their feedback or contact page and send them an email.

This is not a Webcompat issue.

Java Applets

Java Applets were used a lot in the 90s to provide application contexts in Web page when HTML was not enough. It has mostly disappeared in the context of a Web page. If you see a page dependent on Java, no need to report it.

This is not a Webcompat issue.

Tracking Protection List

Firefox and some other browsers have mechanisms to block trackers. If you are accessing a website with a strict tracking protection active. The site is likely to break in some fashions. Sites have a tendency to track all your actions. And some scripts fail when the tracker is not working.

This is not a Webcompat issue.

Ads Blockers/Script Blockers

This is a variation of the Tracking Protection list. Any addon you install has the potential to disrupt the normal operation of a website. It's even more acute when it's about blocking ads or scripts. ADB, uBlock, NoScript are the most current reasons for a website failing. Sometimes you will get a site completely blank or just with the text and no layout at all.

This is not a Webcompat issue.

Desktop site instead of mobile site

When testing on mobile, make sure to test on a device. Receiving a desktop site on a mobile device is frequent. Not all websites have specific versions of their site for mobile, or a website which adjusts itself to the screen context. That said, there are specific case which are worth reporting.

  1. Receiving a desktop site on a mobile device while on the same device, Chrome is receiving the mobile version. Very often this is the result of user agent sniffing. You can report it.
  2. Receiving a desktop site partially visible while Chrome seems to adjust the site to the current screen. This is likely a duplicate of the lack of virtual viewport on Firefox Android. You can report it.

Different mobile versions

Sometimes some websites are sending a different version to two browsers. For example a text only version to one browser and a very graphic one to another browser. It's probably the result of user agent sniffing. You can report it.

Fluid layout

Some websites have fluid or responsive layouts. These layouts adjust well more or less to small screens. When they don't adjust, you might, for example, see a navigation bar with items folding on a second line. These issues are difficult to identify. Your best lead is to test in another browser. If you get the same behavior in both Chrome, Firefox, Edge and Safari on mobile, then it's not a webcompat issue.

This is not a Webcompat issue.

Login/Password required / Credit card required

This one is quite hard and heart wrenching. Many sites require login and password to be able to interact with them. Think social networks, emails, school networks, bank accounts, etc. For a very common site, we might be able to reproduce because some of us have an account on the same sites. But in many occasions, we do not. For example, you want to report a webcompat issue for a private page on your bank. It's unlikely that we will be able to do anything without being able to access the actual page. We are not client on this site. We do not have a credit card for buying stuff you bought.

  1. If you are anonymous, do not report it. There's nothing we can do about it.
  2. If you report it as a github user on webcompat.com, be ready to followup. It's very likely we will not be able to access the page ourselves, but we might be able to guide you in analyzing the issue for finding out the issue.

It might be a Webcompat issue, but it might not be worth reporting it.

Browser features (Reader View, Tabs, etc.)

Browsers all have specific features accessible through what we call the chrome (different from the chrome browser). This is basically things which are part of the browser UI and assists in having a better usage. The best way to report an issue you noticed is to directly open a bug report on the browser vendor reporting system.

This is not a Webcompat issue.

SSL errors

Some sites have very poor security practices or outdated certificates. So when the browser blocks you to access a website with a message saying "An error occurred during a connection to …" is likely an issue with their SSL handling. You can test that yourself by entering the domain name into a validator. Another common reason is the HTTPSEverywhere add-on (and alike) which tried to force redirect to https for all websites. Some sites do not have an https version. Then the site will fail under https, but will work with http. Feel free to contact with a link to the SSL validation.

This is mostly not a Webcompat issue.

Private domain names / Proxies / Routers UI (not on the public internet)

Web UIs are used for many type of applications. Many of them are accessible only in the context of a company network, a local home network, etc.

  1. If the site is not accessible through the public internet and you are anonymous, do not report it. We will not be able to do anything about it.
  2. On the other hand, if you are a github user and you are ready to help us with followup questions and diagnosis, it might be worth reporting.

After the Webcompat sprint (organizers, participants)

It's not about quantity, it's about quality. We try to improve the Web. A larger number of issues might not necessary help us to fix a browser or a website faster. On the other hand, being able to followup on the issues when there are unknown details or additional questions from people triaging and diagnosing is invaluable. Reporting many issues without being able to answer questions afterward because you have no time, or you are not interested, might waste time of many people.

You might want to do additional meetings for specifically following up on these issues. It's a great opportunity to learn how to debug and understand what is happening in a Web page.

Otsukare!

otsukare by Karl Dubost at

When we want to encourage participation, reward is a common technique. Basically you accumulate good karma for your contributions. It's exactly the same as the carrott for the donkey, the bonus salary at the end of the month, the good score at school with the diplomas at the end, etc. These all are of the same family more or less. They can be very poor or very good depending on the process which drives them.

One (recent? in terms of centuries) additional twist on that is the gamification. Humans love to play, let's manipulate them a bit more into doing more work through gamification and let's establish a leaderboard. The leaderboard is the pinnacle of what is wrong with gamification. People are not driven by the game, but are driven by the top of the poster. Their name in shiny gold letters. It rewards often quantity over quality.

What can we do about it?

If you create a leaderboard or a gamification for getting results, focus first on what you brought to the participants of the game. Basically the score should be a mirror on your ability to have made the participants better at what they are supposed to accomplish. What does the organizer bring for the self accomplishment of the participants as individuals or a team?

It's never about volume. All your score system should be based on the data quality. It's often good to introduce negative scoring which removes the will to create volumes. Naively speaking, let's say +1 for the action providing the data, -2 if the data were of bad quality.

It should also be a process where you can't accumulate wealth. Basically, old participants become de facto the top of the leaderboard if month over month, they accumulate their score. This can be mitigated by the score in the last 10 days (choose the meaningful scale for your project). The importance is not the all time score, the importance is to be able to have a regular participation.

Your Leaderboard Guidelines

  • Proficiency over success
  • Quality over quantity
  • Regularity over history

Otsukare!

Mike Taylor's Web Log by Mike Taylor at

Over in web-bug #9726, there's an interesting issue reported against glitch.com (which is already fixed because those peeps are classy):

Basically, they had an HTML <button> that when clicked would display:block a descendent <dialog> element that contained some hyperlinks to help you create a new project.

screenshot of glitch.com button

The simplest test case:

<button>
  <a href="https://example.com">do cool thing</a>
</button>

Problem is, clicking on an anchor with an href inside of a button does nothing in Firefox (and Opera Presto, which only 90s kids remember).

What the frig, web browsers.

But it turns out HTML is explicit on the subject, as it often is, stating that a button's content model must not have an interactive content descendant.

(and <a href> is totally, like, interactive content, itsho*)

Soooo, probably not a good idea to follow this pattern. And who knows what it means for accessibility.

The fix for glitch is simple: just make the <dialog> a sibling, and hide and show it the same way.

* in the spec's humble opinion

otsukare by Karl Dubost at

We often see code benchmarks. Some browser X HTML renderer is faster than browser Y renderer. Some JavaScript engine outperforms the competition by two folds.

While these benchmarks give a kind of instant gratification for the product, they always make me dubious coming from anyone. If the target is to outperform another browser, then I sense that nothing useful has really been accomplished. Even as a marketing technique, I don't think it's working.

When/if publishing a benchmark, focus on three things:

  • How this new code outperform the previous versions of the code? It's good to show that we care about our product and that we want to be faster where/when it matters.
  • How does this improve the user experience on some specific sites? Improving speed in controled environment like benchmarks is nice, but improving speed on real cases Web site is even better. Did it make the JavaScript-controled scrolling faster and smoother?
  • How did we get there? What are the steps which have been taken to improve the code performance? The coding tricks and techniques used to make it faster.

These will be benchmarks blog posts I like to read. So as a summary

Good benchmarks show 1. Outperform your own code 2. Real websites improvement demos 3. Give Technical explanations.

Otsukare!

otsukare by Karl Dubost at

There's always a sequence of things I do before working on a new branch for webcompat.com development.

# Probably one of the most used command for me. (See below)
git status
# back to the master branch
git checkout master
# webcompat is my origin
git fetch webcompat
# updating to the latest version
git merge webcompat/master
# opening a new branch where 1677 is the issue number and 1 is the first attempt.
git checkout -b 1677/1

Most used git commands?

Let's see if my impression was correct.

grep -E '^git' ~/.bash_history | sort | uniq -c | sort -nr | head -n15
 563 git status
 383 git diff
 211 git checkout master
 131 git push origin master
 124 git branch -a
 117 git log
  61 git fetch webcompat
  51 git pull upstream master
  49 git merge webcompat/master
  45 git fetch upstream
  41 git log --oneline
  23 git fetch webcompat;git merge webcompat/master
  20 git pull
  20 git checkout master; git fetch upstream;git merge upstream/master
  19 git fetch upstream;git merge upstream/master

This previous one is too specific because it includes the full line. Let's constraint it to the git option. git status is still the winner.

→ awk '{print $1, $2}' ~/.bash_history | grep -E '^git' | sort | uniq -c | sort -nr | head -n15
 572 git status
 543 git commit
 509 git diff
 501 git checkout
 395 git push
 238 git branch
 193 git log
 186 git fetch
 136 git pull
 116 git add
  96 git merge
  82 git clone
  77 git rg
  37 git rebase
  31 git remote

If you are wondering what git rg is? It is coming from my ~/.gitconfig and is a courtesy of Anthony Ricaud.

[alias]
        rg = "grep --heading --break -i"

Very useful grep baked into git.

Otsukare!

otsukare by Karl Dubost at

We had a working business week for Mozilla All Hands. The big bi-annual meeting of the full company to work, discuss, cooperate and make wonderful things.

These are random notes not work related about thoughts accumulated during San Francisco week. What we notice in spaces and people are primary ourselves. It's often the start of a self-introspection more than anything else.

Meeting with my thoughts

  • crossing the border went smoothly. I was feeling good. No mobile device. Blank laptop.
  • Mission street areas from the bus. A bus of wealthy geeks watching the poor, the abandonned, the drifter from up there behind a window. It takes a blaze and spirit to start a revolution. The spirit is drowned inside the body.
  • This insecure feeling of the touristic areas when you never know if and when a driver will plow into the crowd or someone will draw a gun.
  • Chinatown is peaceful and calming environment for me. Something familiar, something I relate to.
  • The charm of the hills of San Francisco is a beautiful pain to my legs. The effort and the view are a gift.
  • Brands using pseudo-political messages to sell more stuff. Nauseous.
  • Exhausted.
  • Sleeping.
  • Plastic surgery is a thing.
  • Cable cars packed with tourists. Do locals still take the cable cars? Private buses to go to Silicon Valley. Dedicated transportation for tourists… What a broken world.
  • Noisy reception, rooms full of people too loud.
  • The emptiness of ads.
  • Long discussion with a friend walking across the San Francisco streets about everything, about nothing, about simple things. On the road, we share.
  • From coit tower, foggy dark Golden Gate vaporized in the horizon.
  • Sirens of fire trucks are frequent
  • A black old man clapped my hand when crossing and wished me a good day. I replied "you too". I don't know if he heard me.
  • I hear the cable cars tongtong tongtong from the hotel window.
  • Things we hear in SF "Oh crap, can someone stash my kinder eggs?"
  • Industrial buildings and hipster shops. The world of rich people is leveled.
  • Freezing wind.
  • Wonderful broth of a Pho Bo
  • A woman shouting "bitch" multiple times at the window of a Carl's restaurant.
  • The feeling of meeting too many people.
  • The feeling of meeting too few people.
  • A perfume shop clerk, old and elegant woman talked to me English, then Japanese, then French. Smile for the day.
  • Missing the cafe latte barista from Whistler All Hands.
  • USA and too big hotel rooms. Ridiculous use of space in a time where everything should be counted and saved.
  • Written culture of street signs.
  • Walking from the hotel to the bye bye event, a moment for long life discussions.
  • American college kids doing bbq. A certain image of USA.
  • Long streets without any shops.
  • overheard: "Let's start the day with a bloody mary" (at the airport at 8am)

Otsukare!

Mike Taylor's Web Log by Mike Taylor at

7 years ago I tweeted my only good tweet:

please kill the text-shadow in ::selection. obsessive compulsive text highlighters like myself go blind

screenshot of text selection ugliness

(apologies for hideous screenshot, 2010 was a weird time for web design, I guess)

Some internet hipsters agreed, so they put a default text-shadow: none rule for ::selection in html5 boilerplate's main.css.

Anyways, we recently got a bug about nearly same exact issue: if you have a white background and set a white text-shadow on the copy (wat), things can get weird when someone makes a selection:

#wrapper {
  background-color: #fff;
}
.post-meta {
  text-shadow: 2px 0px 1px #fff;
}

So don't do that?

Anyways. The most important takeaway (for me) is that the devs over at thegunmag.com don't follow me on twitter, which is super rude when you think about it.

otsukare by Karl Dubost at

webcompat life

  • Often tracking protection is confusing for people. I always wonder if it's because people are put in front of it in failure situation. Basically you discover something is not working because the site breaks, and you are later on told it is because of tracking protection. It's a negative feeling feature which doesn't show itself when everything is fine. I wonder if there would be a way to reverse that feeling. Something like, an individual site report on the blocking and a daily or weekly stats dashboard explaining what has been blocked. "Congratulations, Tracking Protection has blocked this week X of this, Y of that."
  • Webcompat Minutes published

webcompat issues

webcompat.com dev

Interesting read

Otsukare!

otsukare by Karl Dubost at

webcompat life

  • Jetlag and fatigue. Last week, a part of the Webcompat team had an intense work week in Berlin to discuss the precise parts of developing webcompat.com and the strategies around it.
  • it's my 3rd time in Berlin. À la Sei Shonagon, some pillow book notes:
    • Broken glasses in many streets.
    • People drink in the streets. Sometimes beer. Sometimes in the morning.
    • Organic shops or sections everywhere.
    • April is cold.
    • Graffiti and artsy life very active.
    • Mozilla office is in an area a bit dead.
    • The subway is based on a trust system. Free access to the platforms, punch your card to validate your ticket.
    • Children ride bikes as much as adults. Plenty of bike trailers too.
  • Developer tools and web compatibility

webcompat issues

webcompat.com dev

Interesting read

Otsukare!

otsukare by Karl Dubost at

webcompat life

  • Some issues takes a lot longer to analyze understand than what it seems at the start.

webcompat issues

webcompat.com dev

Otsukare!

When Can I Use updates by Alexis Deveria at

Two new developments to the Can I use site:

1. caniuse.com is now available over HTTPS! There's still a few kinks to work out before that becomes the new default but it's available today.

2. New Patreon account to enable an ad-free experience! When you support the site for as little as $1 USD/month and link your account, ads will no longer be loaded on the page. Once you're a patron just click the log in button at the bottom of the site to link your account. Your contributions are highly appreciated and help keep the site running!

otsukare by Karl Dubost at

webcompat life

  • Working on a replacement for our minutes script.
  • Booking flights to June meeting in San Francisco and thinking about my strategy with regards to data. Each time I book flights I can't help thinking about the absurdity of airlines and booking strategy.
  • My server for this site and a couple of others have changed place. For the last 15 years, my 1U Dell was hosted at W3C MIT. Thank you. I moved to Gandi in the meantime, but I'm exploring also something else.

webcompat issues

webcompat.com dev

Otsukare!

otsukare by Karl Dubost at

webcompat life

webcompat issues

webcompat.com dev

To read

Otsukare!

otsukare by Karl Dubost at

I have seen clever, thoughtful and hardworking people trying to be right about the CSS is not broken and CSS is broken. PopCorn. I will not attempt to be right on anything in this post. I'm just sharing a feeling.

Let me steal the image from this provocative tweet/thread. You can also read the thread in these tweets.

CSS in JS

I guess looking at the image I understood how/why the discussions would never have any resolutions. Just let clarify a few things.

A Bit Of An Introduction

CSS means Cascading Style Sheets. Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents.. Words have meanings. It is 20 years old spec wise. But the idea came from a proposal on www-talk on October 10, 1994. Fast forward, there is an ongoing effort to formalize CSS Object Model aka CSSOM defines APIs (including generic parsing and serialization rules) for Media Queries, Selectors, and of course CSS itself.

Let's look at the very recent CSS Grid, currently in Candidate Recommendation phase and starting to be well deployed in browsers. Look carefully at the prose. The word DOM is cited only twice in an example. CSS is a language for describing styling rules.

The Controversy

What people are argueing about and not discussing or dialoguing about is not about CSS, but how to apply the style rules to a document.

  • Some developers prefers to use style elements and files using the properties of the cascade and specificity (which are useful), aka CSS.
  • Some developers wants to apply the style on each individual node in the DOM using JavaScript to constraint (remove) the cascade and the specificity because they consider it annoying for their use case.

devtools screenshot

I do not have a clear cut opinion about it. I don't think CSS is broken. I think it is perfectly usable. But I also completely understand what the developers who wants to use JavaScript to set style on elements are doing. It makes me uncomfortable the same way that Flash (circa 2000s) or frame (circa 1995) was making me uncomfortable. It is something related with la rouille du Web (The Rusty Web). The perennity of what we create on the Web. I guess in this discussion there are sub-discussions about craft and its love, the Web perennity and the notion of Web industrialization.

There is one thing which rubs me in the wrong direction is when people talk about HTML and CSS with the "in JS" term associated. When we manipulate the DOM, create new nodes and associate style to it, we are not doing anymore HTML and CSS. We are basically modifying the DOM, which is a complete different layer. It's easy to see how the concerns are different. When we open a web site made with React for example, the HTML semantics is often gone. You could use only div and span and it would be exactly the same.

To better express my feeling, let's rephrase this:

You could use only div and span and it would be exactly the same.

It would become.

pronoun verb verb adverb noun conjunction noun conjunction pronoun verb verb adverb determiner noun.

then we would apply some JavaScript to convey meaning on it.

So…

As I said I don't think I'm adding anything useful to the debates. I'm not a big fan of everything apps through JavaScript, maybe because I'm old or maybe because I value time.

I also would be curious for the advocates of applying styles to nodes in the DOM, if they made the experiment of generating (programmatically) a hierachical CSS from the DOM. Basically the salmon ladder in the river to go back to the source. I'm not talking about creating a snapshot with plenty of style attributes, but reverse engineering the cascade. At least just as an experiment to understand the two paths and what we could learn about it. It would minimize the CSS selectors, take advantage of the cascade, avoid as much as possible !important, etc.

Otsukare!

Subscriptions