- [Adrian] Thank you for attending.
My talk CSS Display Properties versus HTML Semantics.
We have a bunch of things
that we are going to cover in this talk.
I've put together a quick agenda.
But don't worry about that so much,
I'll get to everything here.
Hi, I am Adrian Roselli.
I have been building for the web since 1993.
You can learn more about me on my site adrianroselli.com.
You can also avoid me on Twitter
or block me right now @aardrian.
That's A-A-R-D-R-I-A-N.
For a little bit of context,
so that you know the person who is speaking
might have some experience in this stuff
or have a bit of a clue.
I've written some books.
I've written a bunch of magazine articles.
I was one of the co-founders of evolt.org,
used to write for Web Standards Sherpa.
I have a few resource sites like
'Does My Site Deserve Recognition?' and a11y reviews.
I've participated in W3C standards creation for years.
I'm one of the people behind Inclusive Design 24
and I do accessibility editorial work over at A List Apart.
So let's talk about an example use case
for the overall range of my slides here.
Think about an HTML structure that challenges developers
across screen sizes and context.
Think about something where you have to build a layout
that can adapt to screen sizes.
Something that has an inbuilt structure,
with inbuilt semantics where the nodes that are exposed
in the accessibility tree have to be put together
in the DOM in a very particular way.
The example I'm gonna use is HTML tables.
It's a great way to present information in two axes.
They kind of are the perfect proxy
for everything I wanna do.
So let's recap them really quickly.
HTML tables have a long history on the web.
They have been used not just for tabular data
but also for layout since they were first introduced.
That was kind of their thing.
They have a very specific DOM structure.
If you leave nodes out, the thing can fall apart.
They also have their own navigation methods
within screen readers, for example.
A basic HTML table, pretty straightforward.
Avoid spanning cells, make sure you use th for headers,
add a useful caption.
I mean, realistically, coding tables is pretty easy
even if it might be a bit monotonous.
The idea is that it's a series of rows,
consistently coded with a header for each column,
and a caption.
In my example here, I have a table that shows
authors in one column, titles in another,
and years of their books in the final column.
Now you can start to add some complexities to tables.
Row headers is one of those complexities.
You would still use a th element,
but you would add scope attribute
and choose a value as appropriate.
Scope attributes that are valid include:
row, col, rowgroup, and colgroup.
And making sure that your row headers are well-coded,
conforms to WCAG technique H63:
Using the scope attribute to associate header cells
and data cells in data tables.
So this is a pretty straightforward bit of complexity.
In the example I'm showing here,
it's phone numbers and fax numbers
in cities for some people.
And those people's names are essentially the row headers.
Now we can make it a little bit more complex.
Complexity number two would be some spanning cells.
You'd still use a th.
But every th at that point gets its own id
and then every td, every individual cell,
gets a headers attribute.
And the headers attribute points to the id or ids
of the th or ths that you want it to reference.
This conforms to WCAG 2.0 technique H43:
Using id and headers attributes to associate data cells
with header cells in data tables.
Now, generally, spanning is a bad idea.
It has its place.
This example shows homework assignments
or homework percentage when factoring in grades
and compares it to exams and projects across two semesters.
And it uses exams spanning three columns
and projects spanning three columns
to compare first semester, second semester
and then final exam.
This example and the previous example
are both lifted from W3C documents,
showing how to correctly code tables
and these two variations of complexity.
Now responsive design may have been the cause
of some of the resistance to tables that we see today.
A lot of developers are very uncomfortable using tables.
They think that they are the antithesis
of good development practices.
Lists have fared much better for a variety of reasons.
So let's look a little bit at how responsiveness
complicates things.
Specifically for the next few slides,
I'm gonna talk about viewport width.
There's a lot more to responsiveness,
but just the viewport width for this.
Again the tables are typically the bane
of a typical responsive developer.
But I'm showing you here probably the easiest
and least risky approach to make a responsive table.
And namely just letting it scroll off-screen.
Put it in a container,
add a tabindex of zero to that container
so that a keyboard user can tab to it
and then arrow right or left to scroll the view.
Add a role region so that screen readers announce it.
And add aria-labelledby
so screen readers will give it a name.
And, ideally, aria-labelledby will point to
the id of the table's caption.
Simple example here, using my books table,
added a couple more columns,
and we can see it's too wide for that narrow view.
So there is a scroll bar sitting at the bottom.
That's it.
Tab to it, scroll back and forth and you're in good shape.
Now responsive is more than just viewport width.
Even if it were just viewport width,
the scrolling table might not cut it.
I'm still using tables as the example,
but your requirements might demand
some visual restructuring.
One example is having your tables respond to print,
because print is a media query, just like width,
so you ideally would still need to support it.
Similarly, there's Windows high contrast mode
or other display settings.
And these are feature queries.
Ideally, you do nothing on a simple table.
If you're using background colors or background images,
obviously this can complicate things a bit.
Now you might want to try a more novel way
of adapting to a narrow width.
One thing you can do is rearrange the table cells using CSS.
CSS display properties, block, grid and flex,
can all be pretty powerful to do this.
In the animated example here,
I'm showing how the table gets
narrower and narrower and the text wraps
up to the point where it becomes too narrow
and then the table restructures itself
and it stacks all the cells on top of one another.
And even when the viewport is too narrow
to fit all of the width of the text,
there's still a scroll bar on it.
So I've got sort of best of both worlds.
I can still stack it and, in those very rare cases
where somebody scaled the text a lot
and they're on a smaller device,
they can still at least scroll to see everything.
The CSS I'm showing here, pretty straightforward.
I convert everything in the table to block
the table the tr and the td to make the layout easier,
dumping all of the table row and cell styling.
And then for the individual cells,
to make the layout easier, I set it as display: grid.
And then I add my headings, the column headings,
as inline text.
Just a little bit of a view of it in the editor
so you can see how everything comes together.
Now let's talk a little bit about CSS display properties.
The following properties are going to override
native semantics in the browser.
This isn't necessarily how it should be.
But display: block, inline, grid, flex, or contents
are all going to remove the semantics.
You can't use CSS to add it back in either.
So if you're using any of these display properties,
there's the risk that whatever your structure semantics are
can be blown away.
Nothing in the HTML nor CSS specifications mandates this.
Again can't add display: table or display: table-cell
and make the semantics magically come back.
When it comes to assistive technology,
the browsers aren't conveying those semantics
to assistive technology.
So a screen reader, for example,
isn't going to know that something is a table.
So for users who rely on the semantics from a table,
they can be stranded.
They might not be able to understand the content
of rows and columns and those relationships fall apart.
It also means they might not be able
to navigate the content, maybe the entire page
depending on how much information you have.
So I look at tables as sort of a canary in a coal mine.
Breaking semantics of any single
required child element of a table
can break the entire table.
If you're missing a row or a column or row header,
or if the parent table has rows in spans
that have been overridden by CSS display properties,
the whole thing falls down.
You can get a miscount of rows or columns,
so it tells you a number that isn't accurate,
headers can be associated with the wrong data.
And it's hard to see this in action
with elements that don't have so many required children.
Lists don't make this as visible.
So think of tables as sort of code smell.
If your table is broken because of CSS,
you might have this problem somewhere else in your code.
Now I have an example here of GitHub
and how it implements tables by default.
It wants tables to scroll,
because it's very easy for a table to become
wider than their layout, not the viewport,
but their fixed width layout
or their maximum fixed width layout.
So what they do is they put display: block
on the table element instead.
They don't put it in a scrolling container,
they make the table scrollable.
And they do that with .markdown-body table display: block.
That makes the table useless to screen reader users
and useless to keyboard users
because there's not even a tab stop,
there's no tabindex=0 on that table
to allow them to scroll back and forth.
So looking at the example table I had before,
if I restructure that layout just as it is,
don't do anything else, except use the CSS
to make it responsive, it falls down in screen reader.
So what I've done here is I've paired up Firefox with NVDA.
I'm probably not gonna let the whole thing play,
but essentially I'm hitting T to get to the table,
then I'm using control, alt and arrow keys
to navigate the table.
- [NVDA] Books I May or May Not Have Read.
Region, Books I May or Not Have Read.
Table with seven rows and five columns,
Books I May or May Not Have Read.
- [Adrian] I should qualify that this is actually
is the table with the correct semantics
before I've applied the display properties.
And then I've gone and broken it, because I jumped ahead.
- [NVDA] Books I May or May Not Have Read.
Region, Books I May or Not Have Read.
Table with seven rows and five columns,
Books I May or May Not Have Read.
Row one, column one, Author.
Row two, Miguel De Cervantes.
Title, column two, The Ingenious Gentleman
Don Quixote of La Mancha.
Year, column three, 1605.
Row three, 1818.
Title, column two, Frankeinstein;
or, The Modern Prometheus.
Author, column one, Mary Shelley.
- [Adrian] So we could hear that the table that NVDA rather
was announcing the columns as I jumped around
and it told me the column position and row position.
Once I add display properties, though,
and I use those same commands
to try to navigate the table,
things are little bit different.
- [NVDA] No next table.
Not in the table cell.
Author: Miguel De Cervantes.
Title: "The Ingenious Gentleman Don Quixote of La Mancha".
Year: 1605.
Not in the table cell.
ISBN-13: 9783--
- [Adrian] The gist there is that
it doesn't recognize that there's a table on the page
and I can no longer navigate
using standard screen reader navigation,
table navigation commands.
That's why NVDA keeps saying not in a table cell.
So all those relationships are gone,
I no longer have any sense of where I am in the table.
Now it's important to understand
the role of the accessibility tree in all of this.
The accessibility tree is essentially a subset/super-set
of the DOM depending.
It includes user interface objects of the browser
and objects of the document.
So what it does is for anything that fires
an accessibility event or has a property relationship
or feature which needs to exposed, and it's in the DOM,
it gets added to the accessibility tree.
What we're seeing when we look
at the accessibility inspector in the developer tools
in Firefox or Chrome is an abstraction.
It's not a one-to-one correlation
for what the accessibility tree looks like.
So I have here side-by-side images
comparing what the accessibility tree
in Chrome's inspector should look like,
for a standard table, compared to what it looks like
in the accessibility inspector when you've added
any display properties.
On the left, the first image, it shows it's a table,
with a caption, it has rows.
One of those rows has the column headers,
the other rows have cells.
The second image, just by adding that display property,
it now shows it as ignored.
It has no computed properties,
the accessibility node is not exposed,
and that entire accessibility tree
for the table has gone away.
Similarly, for the caption, in both cases I see a caption.
The difference is once I add those display properties
that caption isn't associated with anything.
It's just a piece of text,
floating in the accessibility tree.
Ths go from being a column header
to becoming just an ignored element
that has no accessibility properties.
Same is true with td cells.
They go from being grid cells,
which is the default way that they are exposed
in the Chrome accessibility inspector.
They go from being grid cells to being nothing.
They have no structure,
they are not exposed in the accessibility tree,
and they have no correlation to anything else on the screen.
So this is where things go all wobbly.
Chrome version 80 was released on February 19, 2020.
And one of the things that it explicitly does
is it fixes the flex bug on tables.
What that means is it no longer ignores the table semantics
if you add display: flex to a table.
So this caused me to re-examine
everything I had been looking at overall,
which meant a bit of panicked slide editing
just a couple of weeks before CSUN.
There are other fixes and changes
that are part of Chrome version 80,
and I'll talk a little bit about some of those.
Any browsers that are based on Blink,
the core engine of Chrome,
are gonna benefit from this change.
The latest release of Edge, ChromiEdge,
as opposed to the Legacy Edge, will also benefit from this.
So I have a screen showing a table with display properties
and I have them set to flex.
And when I look at the accessibility inspector in Chrome
I can see that even with flex applied
I'm still in a table, in a row, and in a specific cell
when I'm looking at any particular cell in the table.
This is good because it maintains the semantics,
it creates all the structures I need,
or at least retains those structures,
and it all lives there in the accessibility tree.
The thing that I've highlighted is a flex item
in a flex container.
So the good news here is progress.
But there's a little bit of bad news
associated with this as well.
Namely, the web is not Chrome.
The slide that I'm showing here
is data from the WebAIM Screen Reader Survey number eight,
which was released in September of 2019.
So it's the most recent I have.
It's a survey, which means it's not
exactly perfect research.
And the folks who are answering the questions
skew towards more technically savvy,
but it's still some good insight.
What this shows is that JAWS with Chrome
makes up only 22% of screen reader users.
NVDA with Chrome is another 18%.
We don't know how other assistive technology
is handling how tables are exposed or navigated,
mostly because I ran out of time to test it.
Now I put together some slides comparing what I have found.
Generally, Chrome 80 on Windows 10
does well with flex, grid, block, inline-block and contents.
Tables do just fine.
Headers, buttons all do fine.
The caveat is any lists that have
display: contents set to them fall down
and they lose all of their semantics.
Firefox 73 on Windows 10 has problems
with these display properties on tables.
So ths with flex and grid are announced as cells.
That means they lose their column or row header status.
And a table with display: contents just falls apart.
Lists seem to fare pretty well
when it comes to display: inline-block or display: contents
and inserts a text leaf between each list item.
Bit of a pickle.
And then buttons, when they have display: contents,
Firefox will issue a keyboard use warning.
Safari on macOS 10.15.2 tables are a mess.
Display: flex, grid, block, inline-block, or contents
the tables fall apart, period.
Your lists fall apart for block, inline-block, or contents
with the exception of dl, definition list, description list,
dictionary list or whatever the kids are using.
Headers and buttons fall apart on display: contents.
So right now Safari on macOS 10.15.2
has the most trouble with CSS display properties.
Chrome 80 on Android 10 matches pretty well
with the desktop, desktop version of Chrome 80.
It does well with flex, grid, block, inline-block,
and contents for tables, for lists, for headers and buttons
with the exception of display: contents on lists.
It will ruin your lists.
Safari on iOS just as broken as desktop Safari.
Worth noting that if you have display: block,
inline-block, or contents on a table,
then it treats all cells as belonging in column one.
Kind of annoying.
And a button with display: contents
still fires on double tap with VoiceOver.
So it won't announce it as a button.
But if you accidentally double tap your screen
while doing explore by touch or using the rotor,
you can accidentally trigger something.
Now I mentioned CSS display: table before.
Display: table, table-caption, table-row and table-cell
are all CSS properties that people have used for years
to try to replicate something like vertical centering,
which wasn't always easy to do with CSS.
Each of these display properties will add
layout table semantics in Chrome version 80.
There's no CSS display property to create column
or row headers, though, and it still requires
a well-structured DOM.
And this is not a workaround, it's not a fix,
and it doesn't mean it's okay to use divs as tables.
This is a hack and it's probably not ideal.
Also Chrome doesn't really call it a table
in its accessibility inspector.
It refers to it as a layout table.
So I'm showing the inspector,
specifically the accessibility inspector
pointing at where it should be a table
with a row and grid cell.
I have layout table, layout row table and layout cell table.
This is problematic.
JAWS and Narrator will read this as a table,
but it will not recognize any column or row headers,
because there is no CSS display property
that corresponds to those.
NVDA, VoiceOver and TalkBack will not read this as a table.
A slightly future curveball in Chrome version 82,
it's going to support flex's,
align-items property on buttons.
It's not just flex, but also grid.
So if you're using display: grid, flex,
inline-grid or inline-flex, and use align-items,
this can help.
Primarily, the lack of support for align-items
has hampered uptake of button in layouts
that are grid or flex-based.
Because people couldn't get, or designers couldn't get
the vertical centering or vertical positioning
that they wanted because it would break everything.
So you can expect to see more buttons
with more display properties,
which means more testing will be required
to make sure the semantics are not being dumped.
Now there is a longer version to tables
owing to their misuse for layout,
and people will try other elements
and then try to throw ARIA at them.
I'm really not a fan of using ARIA to fix stuff,
but what we have is a potential
stop-gap measure we can use here.
You can use ARIA to reinsert lost semantics.
So if you make table with a role table,
caption role caption, oh, I should note,
role caption is coming in ARIA 1.2.
It does not exist today.
A thead, tbody, tfoot would get role rowgroup;
a tr gets role of row; role cell on td;
any th with the scope col would be row columnheader;
and any th with the scope row would be role rowheader.
So you're reinserting semantics.
This is potentially good.
This isn't gonna address re-ordered content.
So if you re-layout your table
and move things around dramatically,
you still gonna have some reading order issues potentially.
This also doesn't address any content that you've hidden.
Now I wanna caution you that you should not use grid roles
and you definitely should test with a screen reader.
If your tables are generated from any scripts,
you might wanna update the script
so that it adds these roles for you automatically.
Just builds them in.
Incidentally, on the my site, I have a JavaScript function
that will add these roles for you.
I don't think I included a link at the end of the slides,
but you can pester me afterward and I will point you to it.
Here is what your table with all of this extra ARIA
might look like.
It's a lot more verbose.
Definitely those ths with role of columnheader.
It certainly got more code going on in there.
The advantage, though, is when I fire this up
in a screen reader and browser combination
that is not Chrome 80,
we'll hear that it's going to recognize the table.
So using NVDA, I'm gonna hit T to get to the table
and I'll use control, alt and arrow keys
to navigate the table.
And if you can see what's going on,
you'll note that it's navigating a table as if it's a table,
but all the content is visually stacked.
- [NVDA] Books I May or May Not Have Read.
Region, table, with six rows and five columns,
Books I May or May Not Have Read.
Row one, column one, Author: Miguel De Cervantes.
Row two, Author: Mary Shelley.
Row three, Author: Herman Melville.
Column two, Title: "Moby-Dick"; or, "The Whale".
Column three, Year: 1851.
Row four, Year: 1888.
Column two, Title: "The Hidden Hand".
Row five, Title: "The Great Gatsby".
Row six, Title: 1984.
- [Adrian] So the gist there is that
I am still able to navigate this,
regardless of how it looks.
As a screen reader user, for that set of screen readers,
screen reader users who genuinely don't care
what a table looks like, this is good.
I mentioned ARIA grid.
Do not use ARIA grid roles for simple tables.
ARIA grid is intended to mimic Excel-style spreadsheets.
You don't wanna use this for data tables.
And I'm not covering much more than this in the talk.
Also bear in mind that ARIA grid roles
create a composite widget,
which means your grid, not CSS grid,
but your ARIA grid is one tab-stop in the sequence
and it contains multiple interactive controls.
Every cell is editable.
That's usually not the case with the data table.
And it also means you, as a developer,
have to manage the focus within that table.
Display: contents.
I am seeing this become sort of the new hotness,
or at least I've seen it become the new hotness.
It is something I wanna call out specifically,
primarily because I see some developers using it
as a sort of weird CSS reset.
The way it's a quasi CSS reset
is because it takes the element
and makes it not generate any boxes.
Its children and pseudo-elements still generate boxes,
but otherwise it's just a string of text on the page.
It's almost as if the element has been replaced in the tree
by its contents, by its, as if its opening
and closing tags were removed.
It also yanks things right out of the accessibility tree,
completely.
You can't add it back into the accessibility tree with ARIA.
You can give it an accessible name and all these properties
and all the roles that you want,
but the browser doesn't recognize it
and therefore does not pass it along to screen readers.
So be very careful.
'Cause if you're using display: contents,
it's going to hide all the important reasons
you chose that semantic element from assistive technology.
We know Chrome 80 has just addressed a bunch of issues
and I covered it in the previous slides,
so I'm gonna show an older version of Chrome
in the following slides, which is kinda hard to do
when it's always auto-updating.
But this will demonstrate how you can confirm support
within the browser before you even have to fire up
your screen reader to do some of the testing.
The image on the left shows the inspector
and what the table looks like before any
CSS display properties are in place.
We can see that the computed properties
give it a role of table and it gets its accessible name
from the caption.
The image on the right shows how
once I've added my display properties
the whole thing falls apart.
Once I've added display: contents, I'm sorry.
Once I've added display: contents
it has no computed properties at all,
the accessibility node is not exposed,
the element is not rendered in the accessibility tree.
And you can see under the ARIA attributes section
of the accessibility inspector it still has role of table,
but it's not computed as a table so it's not handed off.
The same is true in on ordered lists.
On the left, it's computed as a list.
On the right, the accessibility is not exposed
even though I'm forcing a role of list.
Same thing with button.
I have ensured that it is a button by using button
and its accessible name comes
from the contents of the button,
and is listening for user entry and other handlers.
I add role button while it has display: contents,
no dice, it's still just a piece of text,
no accessibility information.
With the h2, even when I add aria-level 2
to make it an h2 with a role of heading
it doesn't get exposed.
Typically, the computed properties
would tell me it's a heading at level two,
but not once I add display: contents.
Taking the example that I showed you a few screens ago,
I have a page which has a table and a list
and a button and a heading,
and I've set display: contents on all of them.
I'm gonna have a few seconds here
of trying to navigate that with NVDA in Firefox.
- [NVDA] No next table.
No next list.
No next button.
Table with display
contents heading level two.
Books I May or May Not Have Read.
Author, Title, Year, ISBN-13, ISBN-10,
Miguel De Cervantes, The Ingenious,
Gentleman Don Quixote of--
- [Adrian] So I'll stop it there, because I wanna point out,
I tried to navigate to each of those element types
by hitting the associated key.
T for table, B for button, for example.
And NVDA did not recognize them.
When I start to cursor through and go right to the table,
instead of announcing as columns and rows,
it reads off all the text from the first row,
which are my columns, and then text into the first two cells
of the first row.
That's a bit of a problem.
Now bugs have been filed.
Firefox, Chromium, Safari, and the CSS Working Group
all have open bugs on this.
Even the fixes in Chrome version 80
do not close that Chromium issue.
It's still an open bug, specifically elements
not exposed to accessibility tree
when it is set to display: contents.
So the bugs are out there,
browser makers just need to do something about this.
So you might ask yourself, "Where is my beautiful table,"
you may ask yourself, "Where are the table semantics,"
and you may ask yourself, "Why is this so broken?"
Really, how is this a thing?
Assistive technology is not at fault here.
So it's not the screen reader's fault.
The accessibility information comes from the browser.
Because developers used layout tables for so many years,
screen readers have had to improvise.
They need more than the DOM to understand the page.
So they have developed heuristics for reading tables,
for understanding if it's a layout table or a data table.
It can't really tell when the browser isn't handing
any information at all.
Remember, I'm still using tables as my proxy,
as my canary in the coal mine.
You can't rely on detecting assistive technology
to try and turn off your display properties.
First of all, users don't want to be discovered
as using screen readers.
That's a general problem.
There are some who are fine with it
if they can get a genuinely more accessible experience,
but evidence suggests that doesn't really pan out.
Mouse user or mouse actions are a poor proxy
to identify sighted screen reader users.
It also doesn't map well to people who have
mobility impairments or are using
mobile screen reader with touch gestures.
Disabling a site's CSS for screen readers is impractical.
Do not do it.
CSS itself is not blameless.
CSS already impacts HTML semantics,
so this isn't a new thing really.
Display: none does that today.
Using display: table on its own
does not impart HTML table semantics.
It does give some layout table semantics in Chrome,
but that's not the same.
CSS flex or grid makes it easy for content order
and source order to disagree.
And it's not just flex and grid.
But ever since we've had absolute positioning and floats,
we've had this problem.
Think about how we've used CSS
to vertically center stuff.
I mentioned that for a while.
That's part of how we got into where we are,
assigning table-cell display properties to divs
just so we could do vertical centering.
And, remember, if you use CSS display: grid properties
to layout an HTML table, it still won't
semantically be a table.
First rule of ARIA, don't use ARIA.
Not if you don't have to.
But, yeah, if you are gonna use ARIA,
because this is the only way to fix it right now,
you must understand ARIA, the ARIA that you're using
and the table structure that you're rebuilding.
So it's also gonna require you to keep current
on screen reader and browser support, 'cause things change.
Things change rapidly now that we have browsers
in development cycles that are six weeks,
potentially four weeks.
You'll also have to manage content that you hide
when you reflow the tables such as the column headers.
And you'll have to consider what happens
when your CSS does not load for whatever reason.
So this is not the purpose of ARIA.
Everything I've shown here is just a stop-gap.
I also want to point out the browser is not right.
The CSS spec does not state that semantics
should be dropped.
This is a weird decision that browsers made
that doesn't seem to come from anywhere.
There's no reason to remove the semantics
just because of display properties.
The accessibility tree should not care about most visuals.
Again display: none is a great example where it should.
But, otherwise, it shouldn't break the semantics
for something that's just changing its layout a little bit.
To wrap this up, I have a slide with a bunch of references.
I've written a few things about it.
The first, let's see, one, two, three, four, five.
Well, everything in the left column is stuff I've written
with the exception of the GitHub Contributions Chart.
That's the example that I showed partway through
where I put the, they try to make the table itself scroll
instead of putting it in a container.
Steve Faulkner has talked about display properties
and table semantics.
Heydon Pickering has some information
in his "Data Tables" article.
Ire Aderinokun talks about it
in "How display: contents; Works",
specifically some of the benefits of using display: contents
and balancing a little bit against some of these challenges.
And if you're curious, CSS3, Appendix B
talks about the Effects of display: contents
on Unusual Elements.
These are all handy resources to
maybe try to understand where we are,
or to file bugs on your own.
Again thank you for attending the talk
CSS Display Properties versus HTML Semantics.
I'm not standing right in front of you
so you can ping me with questions.
Find me on Twitter is probably the easiest way
after this is all over and I'm happy to help you out.
Again I am on Twitter @aardrian, A-A-R-D-R-I-A-N.
Thank you again.