> Stretch is tested against Chrome to ensure 100% web compatibility
Erm, no. That’s testing Chrome compatibility (though it’s probably the only one easy enough to test).
Chrome is often rushing ahead to implement features that are either not standardized yet, or will not be standardized, or break exisiting standards and compatibility.
It's the "IE6 Only" of the modern web. I really hoped we (as an industry) would have learned enough from that pain, but I guess not. Institutional Knowledge seems to suffer from serious memory loss.
That's not the point gp is making. You're right of course: Chrome is competent, IE6 definitely wasn't.
Chrome is, however, proprietary and driving further that way. IE6 showed that a single, dominant browser is not good for consumers or progress. Especially when it originates from one of the two leading surveillance tech firms.
[As an aside, I was disappointed to see MS admit defeat with Edge and jump into bed with G. Still seems a bit suspicious tbh].
Competence is also a transient determination. IE6 was highly competent in its time, it is only retrospectively that it "earns" most of its incompetence. IE defined the modern CSS box layout strategy of choice (and realized that box layout model was something underdefined in the specifications), for just one instance. Most of IE6's particular incompetence was the "mic drop" peace-out of Microsoft declaring victory on web browsing and disbanding the team for far too many years; unless you are crazy, you don't "mic drop" on what you think to be an incompetent project, and there's certainly a delicious irony in being considered "too competent" becoming a major part of your core incompetency in a "mic drop" incident.
Sometimes. But motivation matters. The motivation behind ghc is clearly and unequivocally to advance the Haskell ecosystem. The motivation behind Chrome's dominance is another thing entirely.
In addition, the Haskell ecosystem is only one among many programming ecosystems that we can choose among for any given task. If the Haskell ecosystem is a monoculture, and isn't headed in a direction that suits your needs, you can choose another environment.
There's (pretty much) only one Web that needs to serve us all.
Not when one of the concerns is to make it possible to maintain compatibility with it.
Microsoft threw the towel for this very reason. It is quite hard to keep up when you have an implementation used by more than 70% of the market, because that makes it the de facto standard, regardless of what the standard really is.
We are going to see the same issues as with IE6: chrome does (and breaks) things before the standards are updated, and dictate huge chuncks of poorly-thought features on the web platform, that might become required for any kind of serious business (think flash, java, silverlight, widevine).
This really is the E part in EEE (the middle one...)
If you're worried about there being a browser monoculture, being able to fork is useful but not sufficient. For example, suppose Microsoft's new browser gets a large enough share that they (along with Firefox) can veto some of Chrome's changes? Since they have enough technical competence and resources to maintain a branch, upstream doesn't control what they release; they can take changes or not. And they also have ways to gain significant user share.
We are probably past the point where a scrappy new open source browser could gain enough developer talent and user share to be relevant, though. Particularly since it can't be done without mixing in some proprietary code for DRM.
So there may be competition, and a significant chunk of open source code will be involved, but it won't satisfy the folks who want a pure open source browser.
The problem with IE was that it wasn't standards compliant. Oftentimes it seemed they even did so on purpose. Chrome appears to follow the standards nicely. We don't need quirks mode settings to render websites "designed for Chrome".
First, quirks mode wasn't for websites "designed for IE". IE6 already had a quirks mode and a standards mode. Quirks mode was for websites designed for Netscape 3 or so.
For the rest, I work on Gecko (the rendering engine in Firefox). We get a fair number of bug reports about sites that work in Chrome but break in Firefox because Firefox is following the spec and Chrome is not.
Chrome is definitely closer to the standards than IE was, but that's at least in part because of all the changes standards have been making recently to match Chrome when Chrome makes it clear that they have no plans to implement what the standard says. When IE tried that sort of thing, people just wrote standards that didn't match implementation reality. That had its own drawbacks in terms of leading to standards so divorced from reality they were useless (see XHTML 2.0, for example)....
The discussion in https://github.com/heycam/webidl/pull/357 is one example (the Web IDL spec defined the behavior of all the non-Chrome browsers as the spec behavior, then Chrome introduced a third behavior that they want to implement and is trying to get the spec changed to match it).
There were several things in the flexbox spec where Chrome refused to implement what everyone else was doing and the spec ended up getting changed, but I don't have links offhand, sorry. It would take me some hours of digging through bug reports and mailing lists to find them. In general, there have been a lot of things like this in the CSS world that I see peripherally, but I'm not as involved in that personally, so don't have them at the tips of my fingers.
A recent thing that came up is that the behavior of the `disabled` property on `HTMLLinkElement` in Chrome does not match the (very long-standing; literally decades) spec, and it looks like at this point we're going to need to change the spec to match Chrome because sites are writing code to the Chrome implementation, not to the spec, and it's causing compat problems for Firefox (which does implement the spec).
Now don't get me wrong: there are lots of cases in which Chrome _does_ fix longstanding spec-compliance issues. But that's not the only dynamic happening here.
Flexbox is pretty mature though. I'm as much of a critic of the Chrome-only Web as anyone, but in this case it's reasonable to test against Chrome. We have the Web platform tests to make sure Chrome, Firefox, and Safari are interoperable.
Actually it uses webdriver to generate the tests so while we only commit the chrome tests (for simplicity) it is easy enough to run the other browsers locally as long as they support webdriver (which most/all do).
Ironic, too, since Rust is a Mozilla project, designed in large part to keep Firefox competitive with Chrome by allowing low-level optimizations, yet preventing most problems with memory leaks.
Author here. Super excited to see what you are building! We are more than happy to feature it on the Stretch landing page :) Shoot me an email and let's chat!
Interesting! It seems this is a rewrite of Yoga, by the same author, seen by another comment in this thread. So why start again using flex box as a layout engine? For example, there isn't really a good, equally as rich, grid layout engine yet. Also curious what the intended goal with conformance is, as the README states this project has a secondary intent to be more in line with the CSS spec? Personally for me any layout system that can avoid Apple's constraint based system is already a win. I guess, what kind of layout would this enable that Yoga doesn't already?
Stretch doesn't really enable any new kind of layouts that yoga doesn't but it fixes some fundamental problems in Yoga where Yoga was not compatible with the web implementations.
Long term goal of Stretch is to support multiple layout systems including Grid layout I just started with Flexbox because I know that so well :) Look forward to tackling grid layout soonish (contributions / help very welcome).
Super-excited to hear that Grid layout will be coming soonish. Yoga has been fantastic in making Flexbox available "everywhere", but Grid is wonderful for UI layout in a way that Flexbox isn't.
Just to be clear, we are not working on it. However it is something I would like to start looking into sometime soon :) This is a huge area for contributions as I myself am not a grid expert (as apposed to having worked on flexbox engines past 3 years).
> Just to be clear, we are not working on it. However it is something I would like to start looking into sometime soon :)
I hear you, but this is very different to "we're never going to implement this". I might look into contributing, but I've never implemented any layout engine, so I'm not sure how much help I would be!
As someone else who knows nothing about how layout engines work, kudos to this response. I understand time and attention don’t scale well and I hope you don’t get overwhelmed but this kind of attitude in open source is the greatest.
Somethings become very complicated in constraint based systems and they are often much slower in my experience than more special purpose layout systems. That said i'm not against constraint systems either, they just both have their place.
You clearly know your layouts :). I agree, AutoLayout is the most powerful system I've worked with.
I wish others would start their layout systems based on it (others like React Native, or native Android), then add simplified APIs like flexbox using it if needed/desired.
Interesting. Overall, I love iOS constraint engine and really really really miss it when I port things to Android. It's not a universal solution, there's always a point where you flip and do your own layoutSubviews on complex stuff. How does this compare?
Layout is a subject that feels a little bit like a mystic art. There are really no books or accessible material about it, that I know off.
No, the TeX book doesn't count. Looking at the source of Chrome or Firefox doesn't count. Stretch source doesn't count. W3C CSS specs definitely do not count :-p.
I know that there are some papers floating (pun not intended) but I wish somebody wrote a serious book about layout algorithms! Even splitting the words of a paragraph into an optimal shape is something that is surprisingly more complicated and rich topic than one would imagine [1].
Do you know of any resources/docs/papers/implementation-notes that you would recommend?
Hey! I'm actually in the process of writing up a high level overview of Flexbox and how it works. Won't cover all aspects but would make it easier to understand hopefully. Can't promise when I'll post it but hopefully soon at medium.com/visly.
I'm not a UI guy, and I'm definitely not seasoned or have even had the chance to personally test this assertion.... but..
I thought a lot of people disliked Flexbox and preferred CSSGrid? I watched a talk a while back that made it seem like CSSGrid was better in many ways. Primarily being far more inline with peoples natural mental patterns (ie, what they expect). That talk basically had me thinking that the next frontend I write I'm not touching flex box and instead writing it in CSS Grids.
So am I mistaken? Why would people base a framework around Flexbox? Thoughts?
This looks great! I've been using Yoga in my Rust UI framework via the yoga-rs bindings, and this looks like a nice pure-rust alternative to try using instead.
I'm the author of both Yoga and Stretch :) After leaving Facebook I created Stretch to fix some core issues which would be hard to address in Yoga, mainly some web compatibility issues. Would love to know more about what you are building and let me know if I can help in any way with the migration! Adding any missing APIs etc should be very easy.
As a web guy wanting to break out into mobile development, I’m very intrigued by what it says but I have no idea how to make use of this. Can someone give me a light overview?
I wonder what it would look like to put this in wasm and draw it to a full screen canvas, circumventing the dom entirely. I wonder if there would be any benefits.
Of course there are: user cannot block ads, cannot copy text, cannot change scale, robots cannot index the page, it will take more time to load and will work slower.
Hey there! Author of both Yoga and Stretch. I built stretch after leaving facebook because of some fundamental flaws in Yoga which made it not 100% compatible with web browsers. Also I wanted something written in a modern language that was easier to debug, maintain, and innovate on.
Erm, no. That’s testing Chrome compatibility (though it’s probably the only one easy enough to test).
Chrome is often rushing ahead to implement features that are either not standardized yet, or will not be standardized, or break exisiting standards and compatibility.