, and because a

auto-closes an open

, the parser emits an empty p.payment_module followed by a sibling div -- measured: the tile's parent element is div.col-xs-12, not the

, and the

itself is 0px tall. So no anchor is ever a descendant of p.payment_module in this theme, .poPayment is emitted nowhere in the repo, and a.bankwire / a.cheque / a.cash are PrestaShop legacy. They are listed anyway, exactly as PROV-139926 lists them a few blocks up, so the two mobile blocks and the global.css rules they answer all carry the same selector list and a future view that does render one stays consistent. STORE EXPOSURE. 43 purchasing organizations in APS/CustomScripts reference these selectors; 23 of them carry a CSS rule block on one, and 17 of those blocks set a background (16 live -- E83's is commented out). Most of those stores are already asking for this fix by hand: 198, E02, E60, K32, N32, S34 and T98 set "background: none" or "background: transparent" on .creditCardPayment, and the four U21 blocks set "background-image: none !important". Nothing here fights them. The ones that want a background keep it, because GlobalStyles still loads after this file: 336 and E78 replace the icon with their own cash.png through the shorthand, and P98, W02 and R75 re-assert an #fbfbfb fill with !important. All five were replayed at the GlobalStyles position and come out unchanged. The one store group that does change is U21's four blocks. Their !important covers background-image only, so their tiles keep the #fbfbfb fill today and go white on mobile after this. That is the outcome the ticket asks for, and it is mobile-only -- their desktop tiles are untouched. ON EDITING global.css INSTEAD, which the header of this file would normally ask for. This is not a shadowed declaration: the defect is being fixed only below 767px, and global.css:5127-5135 has no breakpoint to attach that to. Desktop keeps the icons and the fill at every width above the breakpoint; whether they should survive there is a design question, not this ticket. VERIFIED by measuring computed style and geometry in headless Chrome over CDP, on a static page that links all 27 platform stylesheets in _LayoutHead.cshtml order against this screen's real markup, at 360 / 375 / 390 / 414 / 768 / 1200px, before and after: * every tile at every mobile width: background-image none, background-color rgba(0, 0, 0, 0), resting and hovered; * border-top still 1px solid rgb(214, 212, 212), and every tile's box unchanged to 0.01px -- this is paint only, nothing moves; * 768px and 1200px byte-identical to origin/Hotfix across every background longhand, border, padding and rect measured; * with PROV-139927's "padding: 10px" simulated after this block, the mobile tiles come out 10px in with no image and no fill, and desktop still 99px with the icon -- the two blocks compose; * replaying each of the 16 stores' own tile CSS at the GlobalStyles position: 336 and E78 keep their replacement cash.png, P98, R75 and W02 keep their !important #fbfbfb, the rest resolve to no background. --------------------------------------------------------------------------- */ @media (max-width: 767px) { p.payment_module a.bankwire, p.payment_module a.cheque, p.payment_module a.cash, .creditCardPayment, .poPayment { background-image: none; background-color: transparent; } p.payment_module a:hover { background-color: transparent; } } /* --------------------------------------------------------------------------- PROV-139923 -- on a phone the specification lines print above the product description in a cart item's detail block. WHICH BLOCK IS "THE PRODUCT DESCRIPTION". The ticket leaves this open and offers three candidates: the product name in td.cart_product, the related products block, or the custom fields block. Only one of them makes the reported observation true, so the reading here is the custom fields. - The product NAME (cartResults.html:35) is in the preceding cell, and the PROV-139637 block above puts td.cart_product at order:1 (:1692) while every other cell takes order:4 (:1630). It is the first thing on the card at every width, so nothing in the detail cell can be above it. - RELATED PRODUCTS is the first of the four includes in the cell (cartResults.html:52), so it is already above the specifications. - The CUSTOM FIELDS (cartResults.html:54) are the one block that renders below the specifications today, which is the only way "specification details render above the product description" can be a true statement about this page. They are also the only block that carries prose: displayCustomFields.html:4 renders an HtmlBlock custom field through to_trusted, which is where a store puts a paragraph of product copy. A cart line has no description field of its own to be confused with -- the properties are Name, Specifications, CustomFields and so on (CartServiceResult.cs:27-71), and Product.Description is rendered only on the product pages, in #short_description_block (productStep1.html:3, productStep2.html:4, productStep3.html:20). So this is a reorder INSIDE td.cart_description, not a move across cells. Measured at 375px, the phone card reads Details Size: Large Colour: Navy Description: Water resistant soft shell ... Care: Machine wash cold ... which is the shape the ticket describes. This is a reading of the templates rather than something the ticket states, and it is flagged on the PR for confirmation. WHAT THE ORDER BECOMES: related products, custom fields, specifications, edit-in-cart fields. Only the specifications actually move. The edit-in-cart block is ordered explicitly so that it keeps the last slot it holds today: it is the one editable thing in the cell and it draws the

above itself (editEditInCartCustomFields.html:1), so letting the specifications fall below it would put read-only text under a form and under that rule. CSS, NOT A TEMPLATE EDIT. Reordering the four ng-includes at cartResults.html:52-55 would reorder desktop too, where nothing is wrong, and those same four includes are emitted again by checkoutCartGrid.html:62-65 for the Payment page. Flex `order` inside the mobile breakpoint leaves every width above it untouched. THE CONTAINER IS NOT A FLEX CONTAINER TODAY. The card stack does not make one -- responsive.css:978 only blocks out the table -- so this rule creates one, on the narrowest element that can carry it: the ng-if="!cartResult.IsCampaign" wrapper at cartResults.html:51, the only element whose children are exactly the four include divs. Measured, that changes three things: - Margin collapsing stops at a flex item, so the 18px hr margins (global.css:291-295) that used to escape displayRelatedProducts.html:24 and editEditInCartCustomFields.html:1 now stay inside those two divs. Net zero: each div grows by 18px and the gap after it shrinks by the same 18px. A bundle row carrying both measured 728.95px tall before and after. - Cross-axis sizing does not change. The children were full-width blocks and are now stretch-aligned flex items of the same width; no min-width:0 is needed because in a column container the automatic minimum size is a min-HEIGHT, not a min-width. - The cell's baseline moves. That is the one thing that needed a second declaration. THE align-self LINE IS LOAD-BEARING, NOT TIDYING. PROV-139637 makes each cell a flex line with align-items: baseline (:1629-1638) so that the "Details" label printed from data-title (responsive.css:965) sits on the first line of its value. A flex container takes its first baseline from its FIRST flex item, and on a line without related products that first item is an EMPTY div: displayRelatedProducts.html is entirely inside an ng-if, so the include renders nothing at all. An empty box has no baseline, one is synthesized at its bottom edge, and the whole detail block drops. Measured without this line, at 360/375/767px: every affected cart_description cell 13px taller (85.7 -> 98.7px at 375px) and the item table 39px longer across the three affected rows. align-self: flex-start takes .mobile_table_content out of the baseline group; the label is then alone in that group, which resolves to the same flex-start, and the geometry comes out identical to today. ONE THING DOES MOVE, and it is deliberate. On a line WITH related products the "Details" label was baseline-aligned into the bundle table and sat 93px down the cell, level with a row in the middle of it. It now sits at the top of the block, where the label on every other cell already sits. Measured at 375px: 504.67px -> 411.25px, which is the top of the cell. Nothing else moves, on any card shape, at any width. SCOPING. #cart-items-container (Views/Cart/Index.cshtml:115) is the unique handle, the same one the PROV-139637 and PROV-139921 blocks above use: #cart_summary on its own is not unique, it is also on Payment's checkoutCartGrid and on campaignSummary.html. The Payment grid could not match these selectors in any case -- its detail cell has no ng-if wrapper between .mobile_table_content and the includes (checkoutCartGrid.html:60-66). Whether the Payment grid should read the same way is a separate question and is not this ticket. "!cartResult.IsCampaign" IN THE SELECTOR is what keeps the rule off the campaign wrapper sitting beside it (cartResults.html:57), whose children are

s under the same parent, so the ng-if expression is the only thing that tells them apart without :has(). ADDRESSING AN ng-include ATTRIBUTE is how one of these four divs gets named at all: they are four identical divs with no id and no class, and the alternative -- :nth-child -- silently follows the wrong div the day a fifth include is added. The attribute survives into the rendered DOM, which 12 of the 230 stores mirrored under APS/CustomScripts already rely on in their own CSS and scripts (e.g. Proforma 489's GlobalStyles carries div[ng-include*="sortPaginationBarBottom.html"] > *). Substring matching keeps the /themes/default/... path in front of the file name out of it. NO STORE COLLISION. 22 of those 230 stores carry a #cart_summary selector and 8 a .mobile_table_content one, but not one references displaySpecifications, displayCustomFields, displayRelatedProducts or editEditInCartCustomFields, and the single .cart_description rule in the whole set -- Proforma U26's GlobalStyles:21 -- colours the related-products