
Improving Chromium's browser compatibility in 2020 - migueldemoura
https://blog.chromium.org/2020/06/improving-chromiums-browser.html
======
sroussey
Here is an example of Google’s homepage not rendering correctly in Chrome:

[https://twitter.com/sroussey/status/1273341472398381056?s=21](https://twitter.com/sroussey/status/1273341472398381056?s=21)

Really, if they have these kinds of problems, then the rest of us... :/

~~~
esprehn
I've seen that one as well (and tagged a rendering lead on Chrome on Twitter
just now). Thankfully it's a painting artifact and not a layout/behavior
issue, likely because the invalidations are not accounting for the way shadows
expand the layer bounds in some situations.

When finding things like this file bugs at
[https://crbug.com/new](https://crbug.com/new)

------
jake_morrison
The compatible problem is Microsoft and Safari, not Chromium and Firefox. I
run a web development agency, and supporting the limitations IE has always
been a significant cost and challenge. As the joke goes, "What is the
definition of HTML5? If it works in IE, it's not HTML5".

I have mixed feelings about Microsoft giving up on their browser. On the one
hand, it will make things more compatible and reduce effort for us. On the
other, it's one step closer to a monoculture controlled by Google. I would
prefer that Microsoft simply get their shit together and make a good browser.

------
DaiPlusPlus
I’m glad to see some traction, finally, for improving <input> elements.
They’re the source of my current pains:

* Still no real combobox. <datalist> is only a half-way solution.

* <optgroup> should be nestable - rarely do things fit into only 2 levels of depth.

* Biggest pain of all: Radio-button events.

~~~
djxfade
And not all browsers support basic features like Datepickers etc. (I'm looking
at you Safari)

~~~
remus
> And not all browsers support basic features like Datepickers etc. (I'm
> looking at you Safari)

This is a real pet peeve of mine. Perhaps there is some good reason, but as
far as I can tell date pickers work well in chrome and firefox, and not having
one in safari means you need to add javascript to your page and/or do some
nasty server side user agent sniffing stuff to try and make sense of dates.

~~~
DaiPlusPlus
It's somewhat ironic (moronic?) that Apple was the first to add support for
`<input type="date" />` in Mobile Safari for the iPhone almost a decade ago -
so it's a complete mystery why macOS Safari doesn't have this feature.

Here's the official WebKit Bugzilla ticket for `<input type="date" />`:
[https://bugs.webkit.org/show_bug.cgi?id=119175](https://bugs.webkit.org/show_bug.cgi?id=119175)

Here's Apple's Radar entry: rdar://problem/14567780 (I don't have access to
Radar - can someone who does please let us know what the latest update is?)

Right now we use a quick-and-dirty date polyfill for macOS Safari - though
more recently our GA stats show that 90% of our macOS users are using Chrome
anyway which supports date inputs natively so for our lesser-used pages and
areas I might forget to add the polyfill and we won't hear any complaints.

~~~
DaiPlusPlus
Thinking about it more - I noticed the WebKit Bugzilla ticket mentions a
problem with integrating Qt's date-picker for other Webkit platforms - and I
noticed that Apple's date-picker in Cocoa is a bit... old-fashioned, I wonder
if Apple's just dragging their feet until they modernize their date-picker in
macOS?

It's kinda mean to do that though - if that is the case then they're
deliberately holding back the web, increasing web-development time, and
worsening accessibility (so many inaccessible JavaScript date-picker
components!) just so that they can avoid "looking bad".

~~~
saagarjha
Fun fact: the bulk of the Cocoa datepicker is one attributed string. Yes, all
the layout and styling.

~~~
DaiPlusPlus
I'm not familiar with Cocoa - can you elaborate on this? What is an
attributed-string and how does a single string define the entire appearance
and interaction of a complex UI component?

------
polskibus
I hope they fix chromium's weird subpixel bugs like this one:
[https://bugs.chromium.org/p/chromium/issues/detail?id=717469...](https://bugs.chromium.org/p/chromium/issues/detail?id=717469#c_ts1513250807)

~~~
bfgeek
We are in the process of revamping our table layout code at the moment - this
should remove subpixel issues like this. Our master bug for these subpixel
issues is:
[https://bugs.chromium.org/p/chromium/issues/detail?id=377847](https://bugs.chromium.org/p/chromium/issues/detail?id=377847)

We expect it'll be ready for testing in a few months. However we expect that
it'll be a bumpy rolling this out as table layout has a long history, and
isn't exactly well defined :).

\- Ian

~~~
polskibus
Please make a large announcement when you are ready to get it to testing on a
wider scale. I'd rather not miss it, and prepare accordingly.

~~~
bfgeek
Will do - we'll make some noise when ready. \- Ian

------
The_rationalist
Microsoft bringing CSS subgrid support to chromium is a beautiful example of
synergetic collaboration! I hope mozilla take notes.

~~~
Izkata
You're probably being downvoted because Firefox has already had subgrid for 6
months (since version 71).

~~~
esperent
It's probably because web devs have experienced years of pain due to MS
holding back the web platform. They've made some positive changes recently but
it'll take them a lot more to atone for past mistakes.

