about summary refs log tree commit diff stats
path: root/test/layout
Commit message (Collapse)AuthorAgeFilesLines
* cssvalues: fix length shorthand parsingbptato2024-12-301-3/+2
|
* cssvalues: fix font-weight parsingbptato2024-12-292-1/+2
| | | | | | you can't bisearch an unsorted map... (also, turn on text styling for colored layout tests because it would have caught this)
* layout: fix various padding bugsbptato2024-12-282-0/+26
| | | | | | | | They need some peculiar conditions to manifest, but the logic errors are clear: * padding contributing to intrinsic minimum size wasn't being clamped * inline padding was being applied twice
* layout: fix a flex sizing bugbptato2024-12-272-0/+14
| | | | | it has to accept percentage sizes too for intrinsic size clamping, it seems
* layout: improve intrinsic minimum size calculationbptato2024-12-269-2/+121
| | | | | It's a fair bit more accurate now on flex-heavy pages. Image sizing remains a broken mess.
* layout: resolve percentage width for auto table cellsbptato2024-12-212-0/+10
| | | | | It is still wrong in case the table is too small, but at least it fixes the regression from 0971ad85.
* cascade: actually, it should be inline-blockbptato2024-12-202-0/+17
| | | | what was I expecting
* cascade: blockify on position: absolute or fixedbptato2024-12-201-0/+1
| | | | | | | | | | | | | | Welp, turns out I was overthinking it. CSS does not support inline position: absolute at all, it just blockifies. That does leave us with the question of "why does inline-block behave differently than block?" Especially because both in Gecko and Blink, getComputedStyle for absolute inline-blocks gives me "block", not "inline-block", and yet there is the same difference in rendering when I change the CSS. I first thought it's a quirks mode issue, but standards mode doesn't affect it. Wat.
* layout: apply padding to intrinsic minimum widthbptato2024-12-192-0/+5
|
* match: fix nested hover selectorbptato2024-12-182-0/+10
| | | | | | | I didn't get it right :( true is the default return value, and true + continue should resolve to false.
* dom, match: optimize :nth-child, :nth-last-childbptato2024-12-172-0/+91
| | | | | | I want to use it in the UA sheet, so the loop won't cut it. (Also fix a parsing bug that prevented "of" from working.)
* Fix test casebptato2024-12-171-1/+1
|
* layout: propagate intrinsic minimum heightbptato2024-12-1712-0/+75
| | | | | | | | | | | | Necessary for flex. Previously we just used the actual height, but that didn't account for boxes that size themselves depending on the available height (mainly just images for now). This also irons out intrinsic min width calculation somewhat, squashing several bugs. I hope it works well. It is a significant change in size calculation, so maybe there are still new bugs lurking.
* layout: do not allow canpx for scFitContentbptato2024-12-152-0/+6
| | | | | The test case attached is undefined in CSS 2.1, but css-sizing-3 wants us to just ignore the width property (I think).
* layout: set table intrinsic min width to specified widthbptato2024-12-152-0/+18
|
* layout: do not trust specified table cell heightbptato2024-12-152-0/+10
| | | | | If the contents are larger than the specified cell height, then it is simply ignored.
* dom, css: fix case-insensitive class/id/attr matchingbptato2024-12-152-0/+21
| | | | Uses an additional lower-case map for O(1) case-insensitive comparisons.
* render: apply visibility to inline boxesbptato2024-12-102-0/+5
|
* layout: override table cell width if its min width is greaterbptato2024-12-102-0/+15
| | | | We can do this now that xminwidth is more accurate.
* layout: another xminwidth kludgebptato2024-12-082-0/+11
| | | | yeah idk
* md2html: another list bugfix, add a testbptato2024-12-041-0/+0
|
* mediaquery: fix and after bare keywordbptato2024-12-012-0/+5
| | | | | no idea what that reconsume was doing there; probably a refactoring mistake
* layout: remove mystery startOffset adjustmentbptato2024-11-281-4/+4
| | | | | | | | Probably a remnant from back when startOffset meant (and was used for) something different. Interestingly, there was already a test case for this, but it was also wrong.
* layout: support br clearbptato2024-11-272-0/+13
|
* layout: another intrinsic min width fixbptato2024-11-241-2/+4
| | | | forgot about word-break
* layout: fix intrinsic min width for words with wrapping opportunitiesbptato2024-11-242-0/+57
| | | | | | | This broke CJK combined with table layouts. (Inline layout's state dependencies between procs are getting a bit scary...)
* chadombuilder: fix removeImpl definitionbptato2024-11-212-0/+3
| | | | | It is documented in chame that parentNode may be nil, and indeed, it is nil in some cases.
* layout: fix intrinsic min width with whitespace: prebptato2024-11-192-0/+11
|
* layout: fix indefinitely sized flex items with boundsbptato2024-11-192-0/+7
| | | | maybe I'll get it right one of these days
* layout: fix crash on overlapping rowspan/colspanbptato2024-11-172-0/+23
| | | | | The rowspan filler must get a smaller colspan if its first cells are occupied by another cell with a colspan > 1.
* layout: fix another flex sizing bugbptato2024-11-142-0/+12
|
* renderdocument: basic stacking context supportbptato2024-11-096-12/+8
| | | | | negative z-index and inline positioning are still not respected, but better than nothing I guess.
* layout: fix a few more flex sizing bugsbptato2024-11-094-0/+34
| | | | | | | | * fix min-width, max-width, etc. not being accounted for properly on the main axis * fix fit-content sizing being overridden for flex items * fix baseline not being set * somewhat unrelated: fix firstBaseline not being set for block boxes
* layout: fix initial flex item width calculationbptato2024-11-085-3/+27
| | | | | | | | | | | | | | | Before, the initial layout of a flex item would have inherited the parent's sizing constraint. This almost worked, except when a descendant of a flex item with an unspecified width would resolve its percentage against this incorrectly inherited width - per standard, this must resolve to auto. Also, the shrink case was wrong, because it did not scale the unit to the respective widths; the standard mandates this as well. Hopefully I got it right this time. Finally, this fixes positioned inline container blocks not being set as the absolute container.
* layout: fix a small table bugbptato2024-11-022-0/+8
|
* layout: remove inline roundingbptato2024-11-022-0/+3
| | | | | | | | | It broke styles like "margin-top: -5px; padding-top: 5px", because the margin would be taken as-is, and the padding rounded to 0. Now they cancel each other out again. (I think I had added this to reduce error caused by line-height, but we don't have line-height anymore.)
* cssparser: fix parsing of unrecognized at rulesbptato2024-11-022-0/+9
| | | | + clean up a bit
* layout: fix yet another inline float bugbptato2024-11-012-0/+8
| | | | | | | | | you can't just set the BFC offset to your own offset when the BFC's origin is your inner offset. (in block layout, this is addressed by initBlockPositionStates & co, but we don't call that for inline because the offset is already resolved there anyway. so this is a special case)
* layout: simplify a bit, fix some inline float bugsbptato2024-11-014-0/+26
| | | | | | | | | | | | | | * simplify "positioned" value calculation: - don't include it in ResolvedSizes, since it's unused in most layouts - resolvePositioned for both absolute and relative positioning - use "size" instead of "space" for absolute positioning - include parent width in layout so that renderdocument does not have to account for it * return bottom margins as regular return values instead of var * fix child bottom margins being discarded in inline floats * fix inline float not including the parent block position in its BFC position
* layout: refactor flow and fix some bugs in the processbptato2024-10-3118-0/+29
| | | | | | | | | | | | * factor out `margin' field from box state * get rid of RootInlineFragment * `nested' -> `children' * get rid of repositionChildren pass; now we handle relative positioning and -cha-center/-cha-right separately * cha-center, cha-right no longer applies to floats * use consistent naming scheme for tests * fix float bottom margin strut not being flushed * fix inline floats changing non-fit-content width
* layout: fix margin resolution for absolutely positioned boxesbptato2024-10-282-0/+15
|
* selectorparser: fix parsing of invalid pseudo elementsbptato2024-10-262-0/+21
| | | | | Found this because the 5th largest tech company on Earth cannot bother itself with trivial matters such as "writing valid CSS".
* cssparser: do not accept invalid rulesbptato2024-10-252-0/+4
| | | | | | This isn't exactly clear from the standard's wording, but e.g. *display: inline must be discarded (because it incorrectly starts with a delim token).
* layout: fix nested absolute positioning, refactor initial size resolutionbptato2024-10-252-0/+25
| | | | | | | | | | Nested position: absolute was broken, so fix it. Also, it makes no sense to dispatch inside layoutBlockChild when we know the expected resolution algorithm upon calling it anyway, so now we do that statically. Finally, fix some bugs in position: absolute size resolution.
* layout: fix inline float + position: absolute bugbptato2024-10-162-0/+6
| | | | | As per standard, float "only applies to elements that [...] are not absolutely positioned."
* layout: fix float positioning in inline contextsbptato2024-10-155-1/+18
| | | | | | also fixes a bug in the previous commit where whitespacenum would be reset on absolute positioning + missing absolute margin handling without top/left/etc.
* layout: correct `position: absolute' (FINALLY)bptato2024-10-158-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a) resolution of `position: absolute' percentage sizes with an indefinite containing block size (wait what?), and b) positioning of `position: absolute' inner block boxes inside inline boxes. a) is possible because `position: absolute' does not affect its parent's layout. I would love to have a long talk with whoever thought that specifying it like this is a good idea. You know, just because you can... anyways, shockingly enough, this was still the more straightforward part. b) forced me to change the box tree to allow blocks inside inlines, which is ugly, but no big deal. Two questions then remained: 1. *where* to put such boxes, and 2. *how large* these boxes should be; this is hardly obvious since an inline box does not have an unambiguous width or height. Of course the CSS standard, never too eager to fulfill my basic expectations, says nothing about this (other than "it's not defined"). So I first tried to reverse engineer what Gecko does, and after hours of pain and suffering I realized... that it's broken LOL https://bugzilla.mozilla.org/show_bug.cgi?id=489100 Therefore I ended up (partially) copying Blink behavior, which, while equally nonsensical as Gecko (and of course divergent), at least does not change after a partial layout. Thank you LayoutNG for saving my sanity. As for the practical benefits: this fixes the bug where Invidious [video] tags wouldn't show up. Hey, it's something! Still left to-do: `position: absolute' for `display: inline' boxes.
* layout, pager: preserve tabs on display, selection & outputbptato2024-10-102-2/+17
| | | | | | | | | | | | Substitute tabs with one of eight PUA characters based on their width, and convert them back in the pager: * TUI mode always prints spaces, but now handles tabs appropriately on cursor movement * dump mode tries to preserve hard tabs, but uses soft tabs when that is not possible (e.g. tabs after a margin, tab with background color, etc) * selection mode always outputs hard tabs.
* layout: fix floats overriding margin/paddingbptato2024-10-054-14/+25
|
* layout: fix wrong padding offsetsbptato2024-09-272-0/+7
| | | | + some misc refactorings
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-18 01:41:18 +0000