Repository: mui/material-ui (TypeScript)
Task type: Refactoring

Issue:
[Lists] Change List and ListItem to use ul and li
We are looking through the semantics of our website, which uses Material-UI, and we discovered that list items in Material UI doesn't use `<ul>` and `<li>` (ie https://github.com/callemall/material-ui/blob/master/src/lists/list-item.jsx#L298). Does anybody know why this is?

[Lists] Change List and ListItem to use ul and li
We are looking through the semantics of our website, which uses Material-UI, and we discovered that list items in Material UI doesn't use `<ul>` and `<li>` (ie https://github.com/callemall/material-ui/blob/master/src/lists/list-item.jsx#L298). Does anybody know why this is?



Discussion:
@bweggersen That's a good question :)

We should probably change it to use `ul` and `li`.

+1 let's keep the semantic of webpages structure correct.

@bweggersen @cgestes are either of you interested in taking this up in a PR?

@oliviertassinari @newoga @mbrookes Let's discuss this too. I think using `ul` and `li` might limit what we can do and hurt composibility, I'm not sure. what do you guys think?

@alitaheri I think this PR is suggesting to change the underlying DOM node to render `ul` and `li` instead of `div`. I don't know how this would hurt composability and I think is more semantic so I'm okay with this change. Anything I'm missing? 

well my only concern is that, `ul` can only contain `li`. if that doesn't limit us, then I'm ok with this too.

Yeah that's fair. I think we'd just have to implement it in a way where ListItems and custom composed components are just wrapped in an `<li>` that don't have any styling. I suppose the only caveat is that browsers more often then not have predefined styling for those tags that we may have to reset to avoid weird rendering issues. But I think it's still worth looking at. 

I think more semantic tags definitely help in terms of finding stuff in the DOM, especially with the inline style approach.

Yeah, keeping the semantic is very good. but limiting somehow. We'll have to investigate this before trying to implement it.

I just wanted to add that semantic HTML is also very important for accessibility. Not having this for example makes things less accessible for people using screen readers. cc: @afercia

@nathanmarks I see `next` is still using `div` by default. Is using `ul` / `li` a possibility, or should I mark as `wontfix`?
Is someone already working on this? If not, How should I go about solving it?
@akshaynaik404 No-one is working on this. If you wanted to help, the [contributing guide](https://github.com/callemall/material-ui/blob/master/CONTRIBUTING.md#asking-questions) has some pointers on how to get started.
@bweggersen That's a good question :)

We should probably change it to use `ul` and `li`.

+1 let's keep the semantic of webpages structure correct.

@bweggersen @cgestes are either of you interested in taking this up in a PR?

@oliviertassinari @newoga @mbrookes Let's discuss this too. I think using `ul` and `li` might limit what we can do and hurt composibility, I'm not sure. what do you guys think?

@alitaheri I think this PR is suggesting to change the underlying DOM node to render `ul` and `li` instead of `div`. I don't know how this would hurt composability and I think is more semantic so I'm okay with this change. Anything I'm missing? 

well my only concern is that, `ul` can only contain `li`. if that doesn't limit us, then I'm ok with this too.

Yeah that's fair. I think we'd just have to implement it in a way where ListItems and custom composed components are just wrapped in an `<li>` that don't have any styling. I suppose the only caveat is that browsers more often then not have predefined styling for those tags that we may have to reset to avoid weird rendering issues. But I think it's still worth looking at. 

I think more semantic tags definitely help in terms of finding stuff in the DOM, especially with the inline style approach.

Yeah, keeping the semantic is very good. but limiting somehow. We'll have to investigate this before trying to implement it.

I just wanted to add that semantic HTML is also very important for accessibility. Not having this for example makes things less accessible for people using screen readers. cc: @afercia

@nathanmarks I see `next` is still using `div` by default. Is using `ul` / `li` a possibility, or should I mark as `wontfix`?
Is someone already working on this? If not, How should I go about solving it?
@akshaynaik404 No-one is working on this. If you wanted to help, the [contributing guide](https://github.com/callemall/material-ui/blob/master/CONTRIBUTING.md#asking-questions) has some pointers on how to get started.

Solution patch:
diff --git a/src/List/List.js b/src/List/List.js
--- a/src/List/List.js
+++ b/src/List/List.js
@@ -75,7 +75,7 @@ type Props = DefaultProps & {
 class List extends Component<DefaultProps, Props, void> {
   props: Props;
   static defaultProps: DefaultProps = {
-    component: 'div',
+    component: 'ul',
     dense: false,
     disablePadding: false,
   };
diff --git a/src/List/List.spec.js b/src/List/List.spec.js
--- a/src/List/List.spec.js
+++ b/src/List/List.spec.js
@@ -16,12 +16,12 @@ describe('<List />', () => {
   });
 
   it('should render a div', () => {
-    const wrapper = shallow(<List />);
+    const wrapper = shallow(<List component="div" />);
     assert.strictEqual(wrapper.name(), 'div');
   });
 
   it('should render a ul', () => {
-    const wrapper = shallow(<List component="ul" />);
+    const wrapper = shallow(<List />);
     assert.strictEqual(wrapper.name(), 'ul');
   });
 
diff --git a/src/List/ListItem.js b/src/List/ListItem.js
--- a/src/List/ListItem.js
+++ b/src/List/ListItem.js
@@ -106,7 +106,7 @@ class ListItem extends Component<DefaultProps, Props, void> {
   props: Props;
   static defaultProps: DefaultProps = {
     button: false,
-    component: 'div',
+    component: 'li',
     dense: false,
     disabled: false,
     disableGutters: false,
@@ -156,7 +156,7 @@ class ListItem extends Component<DefaultProps, Props, void> {
 
     if (button) {
       ComponentMain = ButtonBase;
-      listItemProps.component = componentProp || 'div';
+      listItemProps.component = componentProp || 'li';
       listItemProps.keyboardFocusedClassName = classes.keyboardFocused;
     }
 
diff --git a/src/List/ListItem.spec.js b/src/List/ListItem.spec.js
--- a/src/List/ListItem.spec.js
+++ b/src/List/ListItem.spec.js
@@ -17,12 +17,12 @@ describe('<ListItem />', () => {
   });
 
   it('should render a div', () => {
-    const wrapper = shallow(<ListItem />);
+    const wrapper = shallow(<ListItem component="div" />);
     assert.strictEqual(wrapper.name(), 'div');
   });
 
   it('should render a li', () => {
-    const wrapper = shallow(<ListItem component="li" />);
+    const wrapper = shallow(<ListItem />);
     assert.strictEqual(wrapper.name(), 'li');
   });
 
@@ -44,9 +44,9 @@ describe('<ListItem />', () => {
   });
 
   describe('prop: button', () => {
-    it('should render a div', () => {
+    it('should render a li', () => {
       const wrapper = shallow(<ListItem button />);
-      assert.strictEqual(wrapper.props().component, 'div');
+      assert.strictEqual(wrapper.props().component, 'li');
     });
   });
 


Test patch:
diff --git a/test/integration/MenuList.spec.js b/test/integration/MenuList.spec.js
--- a/test/integration/MenuList.spec.js
+++ b/test/integration/MenuList.spec.js
@@ -29,7 +29,7 @@ function assertMenuItemFocused(wrapper, tabIndexed) {
 
   items.forEach((item, index) => {
     if (index === tabIndexed) {
-      assert.strictEqual(item.find('div').get(0), document.activeElement, 'should be focused');
+      assert.strictEqual(item.find('li').get(0), document.activeElement, 'should be focused');
     }
   });
 }