- From: Xidorn Quan <me@upsuper.org>
- Date: Tue, 26 Apr 2016 01:48:21 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Ting-Yu Lin" <tlin@mozilla.com>
- Cc: "www-style list" <www-style@w3.org>
On Tue, Apr 26, 2016, at 12:50 AM, Tab Atkins Jr. wrote: > On Mon, Apr 25, 2016 at 12:04 AM, Ting-Yu Lin <tlin@mozilla.com> wrote: > > I'm a implementer for Firefox, so this is from the implementation point of > > view. > > > > Tab's proposal is cleaner, but I'm worrying about the implementation > > complexity for defining ::marker to be another universal pseudo like > > ::before for solving the issue for summary implementation. > > I'm curious what the impl complexity is - you already have code to > handle creating ::marker for display:list-item, list-item is basically block + ::marker, so we just create the related render object (we call it nsBulletFrame currently) for block when the display value is list-item. We haven't even supported inline-list-item yet (seems neither does any other browser), because it isn't that important, but it is non-trivial to implement. > and you have code to handle ::before/after pseudo-elements on all > elements. Are the two too hacky to simplify reasonably? IIRC, ::before/after are... very hacky. Code to handle them spreads across the codebase for us, so it is probably not that easy to simplify. And I suspect this specific issue probably isn't worth the effort to refactor that code... Also by allowing ::marker for every element, you'd basically need it to be a full-featured pseudo-element like ::before/after. But it seems to me that, we didn't have conclusion about positioning and layout of a full-featured ::marker even it is only built with list-item, which is why the status of ::marker in CSS Pseudo-Elements 4, and the trimming plan for CSS Lists 3 [1]. Have you had clear idea how to handle that now? [1] https://lists.w3.org/Archives/Public/www-style/2015Mar/0363.html - Xidorn
Received on Tuesday, 26 April 2016 08:47:21 UTC