Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving Chromium's browser compatibility in 2020

blog.chromium.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Improving Chromium's browser compatibility in 2020

#11

Post by remus »

djxfade wrote: post #9
DaiPlusPlus wrote: post #5

I’m glad to see some traction, finally, for improving elements. They’re the source of my current pains: * Still no real combobox. is only a half-way solution. * should be nestable - rarely do things fit into only 2 levels of depth. * Biggest pain of all: Radio-button events.

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

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

Re: Improving Chromium's browser compatibility in 2020

#12

Post by DaiPlusPlus »

remus wrote: post #11
djxfade wrote: post #9

Earlier quoted context omitted.

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

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

It's somewhat ironic (moronic?) that Apple was the first to add support for `` 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 ``: 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.

Re: Improving Chromium's browser compatibility in 2020

#13

Post by DaiPlusPlus »

DaiPlusPlus wrote: post #12
remus wrote: post #11

Earlier quoted context omitted.

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

It's somewhat ironic (moronic?) that Apple was the first to add support for ` ` 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 ` `: 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…

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

Re: Improving Chromium's browser compatibility in 2020

#14

Post by esperent »

DaiPlusPlus wrote: post #13
DaiPlusPlus wrote: post #12

Earlier quoted context omitted.

It's somewhat ironic (moronic?) that Apple was the first to add support for ` ` 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 ` `: 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…

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, inc…

> It's kinda mean to do that though - if that is the case then they're deliberately holding back the web

Kind of like the way they refuse to support open formats like WebGL2, glTF, webP, various compressed GPU texture formats and probably lots more I'm not aware of.

Apple devs always answer "we're working on it" when pressed on these issues. But after several years of seeing the same half-hearted answers these assurances start to ring hollow.

Re: Improving Chromium's browser compatibility in 2020

#15

Post by esperent »

Izkata wrote: post #10
The_rationalist wrote: post #2

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

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

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.

Re: Improving Chromium's browser compatibility in 2020

#16

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

Re: Improving Chromium's browser compatibility in 2020

#17

Post by polskibus »

bfgeek wrote: post #8
polskibus wrote: post #7

I hope they fix chromium's weird subpixel bugs like this one: https://bugs.chromium.org/p/chromium/issues/detail?id=717469...

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

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.

Re: Improving Chromium's browser compatibility in 2020

#18

Post by bfgeek »

polskibus wrote: post #17
bfgeek wrote: post #8

Earlier quoted context omitted.

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

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.

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

Re: Improving Chromium's browser compatibility in 2020

#19

Post by saagarjha »

DaiPlusPlus wrote: post #13
DaiPlusPlus wrote: post #12

Earlier quoted context omitted.

It's somewhat ironic (moronic?) that Apple was the first to add support for ` ` 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 ` `: 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…

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, inc…

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

Re: Improving Chromium's browser compatibility in 2020

#20

Post by DaiPlusPlus »

saagarjha wrote: post #19
DaiPlusPlus wrote: post #13

Earlier quoted context omitted.

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, inc…

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

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?
Post reply on HN