New issue
Advanced search Search tips

Issue 594628 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature



Sign in to add a comment

CSS counter

Reported by lydianhw...@gmail.com, Mar 14 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36

Example URL:

Steps to reproduce the problem:

Steps to reproduce:

I tried to use the CSS Counter property to format the numbering of a nested ordered list. However, because the order list had slightly improper formatting, the numbering is wrong.

Because the nested OL is generated in a content-editable <div>, the ordered list is not properly formatted. The sublist <ol> are direct children of the parent <ol>, instead of being of sublists being children of <li> elements.
Proper formatting of the list would appear as follows:
   <ol>
     <li>item
       <ol>
         <li>subitem</li>
       </ol>
     </li>
   </ol>

The improper html generated from manipulating lists in a content-editable div is as follows:

<ol>
   <li>item</li>
   <ol>
     <li>subitem</li>
   </ol>
</ol>

What is the expected behavior?
Chromium should terminate the CSS counter for a list level when it encounters an </ol> tag. This would result in proper numeration for ordered lists.

(1) expected value: (1)
(2) expected value: (1)
      (1) expected value: (1)
      (2) expected value: (2)
      (3) expected value: (3)
             (1) expected value: (1)
      (4) expected value: (4)
(3) expected value: (3)

What went wrong?
In poorly formatted lists, the CSS counter does not work as expected. It appears that Chromium must encounter an </ol> tag and an </li> tag, before returning to the counter for the higher list level. 

(1) expected value: (1)
(2) expected value: (1)
      (1) expected value: (1)
      (2) expected value: (2)
      (3) expected value: (3)
             (1) expected value: (1)
      (2) WRONG VALUE. expected value: (4)
(4) WRONG VALUE. expected value: (3)

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? No FireFox 45,0

Chrome version: 49.0.2623.75  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 20.0 r0
 
Screenshot from 2016-03-14 14-03-05.png
113 KB View Download
bug.html
4.3 KB View Download
Components: Blink>CSS

Comment 2 by loyso@chromium.org, Mar 28 2016

Labels: -OS-Linux -Type-Compat OWP-Type-ChangeBehavior OS-All Type-Feature
Status: Available (was: Unconfirmed)

Comment 3 by nainar@chromium.org, Feb 13 2017

Labels: Update-Quarterly
Labels: -Update-Quarterly
Project Member

Comment 5 by sheriffbot@chromium.org, Dec 6

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
This is the intended behavior and matches other browser implementations.

Sign in to add a comment