Avoid blowing up stack with bad content.
rdar://110312738
Pull request: https://github.com/WebKit/WebKit/pull/15088
Committed 265309@main (c9ac90f8cbfa): <https://commits.webkit.org/265309@main> Reviewed commits have been landed. Closing PR #15088 and removing active labels.
This feels a little dangerous, though… maybe? I could see a situation where someone imports CSS that nests under a selector, and the imported CSS nesting level + the local CSS nesting level exceed 128 lines This gets much harder if a lib nests a lib that nests a lib, and so on… As a package maintainer, this is a significant reason to go on either… * not nesting my CSS at all if I can help it * using/building a preprocessor to un-nest my nested CSS before package distribution
One consideration that might work around this issue is if the limit only exists per CSS file, but if you can contextually import a CSS file at any layer and have that imported CSS actually **be** nested in the place you import it, and if your CSS file gets the 128 limit, but then so does the imported file, resulting in a great total limit. If the true goal of this change is to avoid bad, deeply nested content, this should still achieve the same goal of avoiding any insane level of nesting in a CSS file, while allowing the flexibility of importing CSS without any unexpected interaction of the file limits. So imported CSS files would get their own fresh reset 128 limit, even if they are nested at the deepest 128th level of another file.
Brandon: I'm not sure I understand the danger ? @import is only valid at the top of a stylesheet, never under any kind of nesting.