Problem: Blink list-item-position is inside for unstyled list items

Problem: Blink list-item-position is inside for unstyled list items

The <li>HTML elements that is not within <ul> / <ol> parent elements has a nonstandard hard coded non-overridable
list-style-position: inside like behavior.

It looks like Gecko based browsers doesn't have this behavior. 

Solution: To remove the 'notInList' flag along with its setters and
getter methods. 'notInList' flag is responsible for creating "list-style-position: inside" like behavior. 

BUG=590094

[venkatvb, 2016-10-29 13:58:53]

The CQ bit was checked by venkateshbabu95@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-29 13:58:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-29 13:58:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-29 13:58:57]

Dry run: No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[venkatvb, 2016-10-29 14:07:08]

Description was changed from

==========
Problem: Blink list-item-position is inside for unstyled list items

Solution: To remove the 'notInList' flag along with its setters and
getter methods.

BUG=590094
==========

to

==========
Problem: Blink list-item-position is inside for unstyled list items

Solution: To remove the 'notInList' flag along with its setters and
getter methods.

BUG=590094
==========

[venkatvb, 2016-10-29 14:07:08]

venkateshbabu95@gmail.com changed reviewers:
+ phistuck@chromium.org, skobes@chromium.org

[venkatvb, 2016-10-29 14:07:38]

venkateshbabu95@gmail.com changed reviewers:
+ phistuck@gmail.com

[PhistucK, 2016-10-29 20:00:37]

First, the description is not so accurate -
<li> that is not within <ul> has a nonstandard hard coded non-overridable
list-style-position: inside like behavior.

Second, as outlined in
https://bugs.chromium.org/p/chromium/issues/detail?id=590094#c5 - I think this
needs an intent to ship and/or a use counter. Pages might depend on this
nonstandard behavior and experience visual glitches as a result.

[PhistucK, 2016-10-29 20:29:21]

On 2016/10/29 20:00:37, PhistucK wrote:
> First, the description is not so accurate -
> <li> that is not within <ul> has a nonstandard hard coded non-overridable
> list-style-position: inside like behavior.
> 
> Second, as outlined in
> https://bugs.chromium.org/p/chromium/issues/detail?id=590094#c5 - I think this
> needs an intent to ship and/or a use counter. Pages might depend on this
> nonstandard behavior and experience visual glitches as a result.

The history of this change would help, by the way.
I see that it goes back to the KHTML days. I do not have a development machine
or Git installed, but if you could follow the instructions -
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ux61oVQz8wo
And see if the commit that actually added this hack (<li> not within <ul> always
have list-style-position: inside) has any useful reason for that, that would
help understanding the actual motive and making a more educated and informed
decision.

[PhistucK, 2016-10-29 20:31:37]

On 2016/10/29 20:29:21, PhistucK wrote:
> On 2016/10/29 20:00:37, PhistucK wrote:
> > First, the description is not so accurate -
> > <li> that is not within <ul> has a nonstandard hard coded non-overridable
> > list-style-position: inside like behavior.
> > 
> > Second, as outlined in
> > https://bugs.chromium.org/p/chromium/issues/detail?id=590094#c5 - I think
this
> > needs an intent to ship and/or a use counter. Pages might depend on this
> > nonstandard behavior and experience visual glitches as a result.
> 
> The history of this change would help, by the way.
> I see that it goes back to the KHTML days. I do not have a development machine
> or Git installed, but if you could follow the instructions -
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ux61oVQz8wo
> And see if the commit that actually added this hack (<li> not within <ul>
always
> have list-style-position: inside) has any useful reason for that, that would
> help understanding the actual motive and making a more educated and informed
> decision.

I forgot to mention, this is the line at the initial commit of WebKit, which is
basically a copy of KHTML at the time -
https://chromium.googlesource.com/chromium/src/+blame/d869b93fe74f4d6cb2dd6f6...

[venkatvb, 2016-10-31 11:20:54]

Description was changed from

==========
Problem: Blink list-item-position is inside for unstyled list items

Solution: To remove the 'notInList' flag along with its setters and
getter methods.

BUG=590094
==========

to

==========
Problem: Blink list-item-position is inside for unstyled list items

The <li>HTML elements that is not within <ul> / <ol> parent elements has a
nonstandard hard coded non-overridable
list-style-position: inside like behavior.

It looks like Gecko based browsers doesn't have this behavior. 

Solution: To remove the 'notInList' flag along with its setters and
getter methods. 'notInList' flag is responsible for creating
"list-style-position: inside" like behavior. 

BUG=590094
==========

[venkatvb, 2016-10-31 11:38:44]

On 2016/10/29 20:00:37, PhistucK wrote:
> First, the description is not so accurate -
> <li> that is not within <ul> has a nonstandard hard coded non-overridable
> list-style-position: inside like behavior.
> 
> Second, as outlined in
> https://bugs.chromium.org/p/chromium/issues/detail?id=590094#c5 - I think this
> needs an intent to ship and/or a use counter. Pages might depend on this
> nonstandard behavior and experience visual glitches as a result.

I agree. It looks like Gecko based browser doesn't have this behavior (if <li>
element is not surrounded by parent <ol> / <ul> )

[venkatvb, 2016-10-31 11:42:26]

On 2016/10/29 20:29:21, PhistucK wrote:
> On 2016/10/29 20:00:37, PhistucK wrote:
> > First, the description is not so accurate -
> > <li> that is not within <ul> has a nonstandard hard coded non-overridable
> > list-style-position: inside like behavior.
> > 
> > Second, as outlined in
> > https://bugs.chromium.org/p/chromium/issues/detail?id=590094#c5 - I think
this
> > needs an intent to ship and/or a use counter. Pages might depend on this
> > nonstandard behavior and experience visual glitches as a result.
> 
> The history of this change would help, by the way.
> I see that it goes back to the KHTML days. I do not have a development machine
> or Git installed, but if you could follow the instructions -
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ux61oVQz8wo
> And see if the commit that actually added this hack (<li> not within <ul>
always
> have list-style-position: inside) has any useful reason for that, that would
> help understanding the actual motive and making a more educated and informed
> decision.

I tried a git blame on the file
"third_party/WebKit/Source/core/html/HTMLLIElement.cpp", 

Below are the CR's added this behavior, 

1. https://codereview.chromium.org/368733002/#ps1
2. https://codereview.chromium.org/1759173002

Need to look into this CR's to figure out why its been added. 
Thanks.

[PhistucK, 2016-10-31 12:03:23]

I found the original offending commit -
https://quickgit.kde.org/?p=kdelibs.git&a=commit&h=f5e6665ad7cbf8208b8194d6f5...

Unfortunately, it does not explain the fix. It just goes on and fixes it... I
guess it just did not look right to the developer at the time. :|

[PhistucK, 2016-11-09 09:42:56]

On 2016/10/31 12:03:23, PhistucK wrote:
> I found the original offending commit -
>
https://quickgit.kde.org/?p=kdelibs.git&a=commit&h=f5e6665ad7cbf8208b8194d6f5...
> 
> Unfortunately, it does not explain the fix. It just goes on and fixes it... I
> guess it just did not look right to the developer at the time. :|

Venkat reached out to Lars, the original author of the change and he actually
responded. :)
He says it was probably done to match Internet Explorer at the time.
I just checked Internet Explorer 11 using previous document modes. Internet
Explorer 7 and earlier render like Chrome.
So, yes, KHTML matched old Internet Explorer at the time, but while Microsoft
fixed that quirk, KHTML derivatives remained quirky.

The only remaining question is whether sites depend on this behavior...

[skobes, 2017-08-21 18:24:14]

skobes@chromium.org changed reviewers:
- skobes@chromium.org