thepaciellogroup / html5-h Goto Github PK

View Code? Open in Web Editor NEW

66.0 66.0 5.0 461 KB

custom heading element

License: MIT License

CSS 1.06% Shell 1.03% HTML 97.91%

html5-h's People

Contributors

Stargazers

Watchers

Forkers

derekjohnson bkardell sunbox benjohnston kublaj

html5-h's Issues

I like this proposal, but not naming anything <html5-*>

I see in the original xhtml2 spec the tag was called <h> I'm not clear why this was rejected (other than being a bit cryptic), can I propose <heading>?

If this becomes standard we'll be using it in 10 years when we're on html 6/7/whatever so timestamping tag names seems a clear mistake.

The html5 doctype got this right.

Replace <xmp> tag

I know that this is a bit outside the main purpose of this repo, but I think it would be more appropriate to use <pre><code> to wrap the code instead of <xmp>.

Spec for `level` attribute

Here is how the level will be worked out. We encourage people to use the first "it works out the level automagically" approach.

When level is not present, the nesting level is calculated from the document structure (as originally), and aria-level and level are set to that level.
- If level is present, but is not a non-zero positive integer, a console message is logged and the unusable value is ignored (so the document structure is used, as above).
When level is present and is a non-zero positive integer, it is preserved and aria-level is given the same value. The document structure is not used.

IE UA styles

have the UA styles for matching heading level depth for blink/webkit and firefox, need IE

-webkit-any not working on mac

-webkit any styles not working on mac chrome/webkit

This is a neat project, but the Polymer polyfill is overkill. A fairly robust polyfill could be written in < 500 bytes. For instance, this polyfill assigns the appropriate role and level to all headings in all modern browsers (read: IE9 and up) even when the DOM tree changes.

propose sister element w3c-h extends h1

we could use h1 and extend it
<h1 is="w3c-h">

using the same code etc we already use. this has the advantage that the base element is a heading. and the fallback (for non js) is a flat structure, but a heading at least have a look at http://rawgit.com/ThePacielloGroup/w3c-region/master/index.html for which i have created both full custom and div extension.

providing logical heading structure with empty sections/articles

currently if a section is empty it still counts as part of the outline for assigning heading level - for example on this test page http://thepaciellogroup.github.io/w3c-heading/index1.html the logical heading level 3 is assigned a level of 4 due to nesting. I suggest it would be better to only step down a level if the previous sectioning element had a heading. thoughts?

Proposing a `level` attribute so knowledge of ARIA is not needed for styling

[ This is related to #8 but is being done for different reasons and I think we need a discussion about it as a separate matter. ]

Currently for styling the element (from the end-user's perspective) we can do the following.

w3c-heading[aria-level="n"] {
  . . .
}

However this is not intuitive to people who do not understand ARIA or even know that it exists -- and yet these are the people we are writing this element for. Therefore I propose that we have a level attribute that mirrors the existing aria-level attribute, so that we can do styling like this...

w3c-heading[level="n"] {
  . . .
}

I got the idea when I got my http://inclusivedesign24.org slides slightly wrong ;-) -- but I do think it's a valid point -- the user of our element should not need to know ARIA.

What do others think?

What if I move the heading around?

I might be wrong, but I don't believe Polymer's ready callback will run if you remove the element and re-insert it deeper in the outline tree. In which case it will still have the old level. Seems bad?

script to apply correct aria-level dependent on outline depth

need script

What if I move the heading's parents around?

Even worse than #25, what if I have

<!DOCTYPE html>
<section id="x">
  <section id="y">
    <html5-h>Hi</html5-h>
  </section>
</section>

and then do

var y = document.querySelector("#y");
y.remove();
document.body.appendChild(y);

thus giving the new tree

<!DOCTYPE html>
<section id="x">
</section>
<section id="y">
    <html5-h>Hi</html5-h>
</section>

I believe (but could be wrong, not having brushed up on Polymer!) that this will still have the old outline depth.

Tests!

Whilst test-driven development (TDD) would've been good, at least the structure of this code is constrained and simple. However, this thing does need testing! There should be a test for all of the attributes (i.e. the role and the various nesting situations that may arise).

Make a version of <w3c-h> that extends <h1>

Edit: For some reason I opened this instead of adding to #14; whoops!

We need to ensure we re-use as much code as possible (from the Polymer API docs it seems we may be unable to use the exact same code for both). However, there is probably a lot of scope for re-use. Need to balance this with hopefully not needing a build system for such a simple repo.

Finally: ensure that the attribute declaration and other works in-progress are done first.

Finally finally: ensure that the README is updated to indicate that the <h1 is="w3c-h" ...> pattern is "just for now" and for when people are not using HTML5 sectioning elements exclusively and hopefully <h> will make it into the spec at some point to render this pattern obsolete.

@stevefaulkner is there anything I need to add/amend?